> Retaining a DTMManager will indeed retain the documents it has cached, > which is not what you want in this case. > > To solve this, I believe you can simply discard the Transformer after use, > and obtain a new one from the TransformerFactory. Since the DTMManager is > associated with the Transformer, this should result in flushing the cache > and starting a new one.
I don't re-use or hang on to Transformer instances. For the majority of transformations, I have a Templates object on which I call Templates.newTransformer() and execute the transform. For all other cases, I do a TransformerFactory.newTransformer() for the transformation and discard the Transformer when done. I noticed some other things that seem a bit odd to me while exploring the heap dump. First, the majority of the DTM instances in the m_dtms array are org.apache.xml.dtm.ref.dom2dtm.DOM2DTM objects, while just a few are org.apache.xml.dtm.ref.sax2dtm.SAX2DTM objects. I can only find a couple of places where I might be using a DOMSource, and those would not be called very much at all. The majority of transformations are handed a StreamSource. Then, I poked around some of those DOM2DTM instances, and found many that seemed to consist of a DocumentImpl instnace with many thousands of ElementImpl named "token" (I'm looking at one that has 94588 of these ElementImpl's referencing it) with a single TextImpl child node that contained fragments of XML... but the fragments don't seem to correlate to transformations that I have been able to track down. What's also odd to me is that the DocumentImpl's docElement and firstChild fields are null. But each of those 94588 ElementImpl's ownerDocument and ownerNode fields are that DocumentImpl instance. What might create such a structure... a document without a root element but referred to by 100,000 elements of <token>xyz</token>? -- m@
