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
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
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.el.xml.TransformTag classes directly uses the
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
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: