Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Enterprise Edition >

Transparently cache XSL transformations with JAXP

Boost performance and retain usability by implementing implicit caching inside transformer factories

By Alexey Valikov, JavaWorld.com, 05/02/03

  • Print
  • Feedback

No doubt, XSLT (Extensible Stylesheet Language Transformations) is a powerful technology that has many applications in the XML world. In particular, numerous Web developers can take advantage of XSLT at the presentation layer to gain convenience and flexibility. However, the price of these advantages is higher memory and CPU load, which makes developers more attentive to optimization and caching techniques when using XSLT. Caching is even more important in Web environments, where numerous threads share stylesheets.

In these cases, proper transformation caching proves vital for performance. A usual recommendation when using the Java API for XML Processing (JAXP) is to load transformations into a Templates object and then use this object to produce a Transformer rather than instantiate a Transformer object directly from the factory. That way, a Templates object may be reused to produce more transformers later and save time on stylesheet parsing and compilation. In "Top Ten Java and XSLT Tips," Eric Burke gives the following code in Tip 1: 

Source xsltSource = new StreamSource(xsltFile);
TransformerFactory transFact = TransformerFactory.newInstance();
Templates cachedXSLT = transFact.newTemplates(xsltSource);
Transformer trans = cachedXSLT.newTransformer();


In this example, transformation from the xsltFile is first loaded into the cachedXSLT Templates object, which is afterwards used to create a new transformer object, trans. The advantage is that later, when we need yet another transformer object, parsing and compilation phases may be skipped: 

Transformer anotherTrans = cachedXSLT.newTransformer();


Although this technique positively influences performance (especially when using the same stylesheets repeatedly, like in Web applications), honestly, it is not convenient for the developer. The reason is, apart from the Templates-based transformer instantiation, you must care about observing the date of the last stylesheet modification, reloading outdated transformations, providing safe and efficient multithreaded access to the stylesheet cache, and many other small details. Even a natural move—encapsulating all the required functionality into a standalone transformer cache implementation—will not save a developer from third-party modules, which use standard JAXP routines without any caching. A good example of such a module is a JSTL x:transform tag: its current implementation in the org.apache.taglibs.standard.tag.common.xml.TransformSupport and org.apache.taglibs.standard.tag.el.xml.TransformTag classes directly uses the TransformerFactory's newTransformer(...) method. Obviously, x:transform will not be able to take advantage of any external caching implementation.

There is, however, a simple and elegant solution to this problem. As long as JAXP allows us to replace a used implementation of the TransformerFactory, why don't we simply write a factory that would have intrinsic caching capabilities?

This idea is not difficult to implement. We could extend any suitable TransformerFactory implementation (I use Michael Kay's Saxon 7.3) and override the parent's newTransformer(...) method so that transformations loaded from the file-based stream sources are cached and returned from the cache, if the transformations were not modified since the last load. A new version of the newTransformer(...) method looks like the following:

  • Print
  • Feedback

Resources