Simon,
Thanks for reporting the problem. The problem is also in the main
Extensions class. The Xerces web page says that the DOM implementation is
not thread-safe.
We used to create one Document object in every extension function call. A
user complained that he ran out of memory by repeatedly calling the
tokenize extension. Now we cache the Document object to reduce memory
usage. As you said, this can cause race condition. I will make a change to
lock the Document before it is used.
Morris Kwan
XSLT Development
IBM Toronto Lab
Tel: (905)413-3729
Email: [EMAIL PROTECTED]
Simon Kitching
<simon@ecnetwork. To: [EMAIL PROTECTED]
co.nz> cc:
Subject: xalan-J : possible
thread-safety problem in ExsltStrings
11/24/2002 03:08
PM
Please respond to
xalan-dev
Hi All,
In class org.apache.xalan.lib.ExsltStrings, a static member of type
"Document" is kept around to be used as a factory for Elements, etc.
The object is created using the normal expression:
lDoc =
DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument().
There is, therefore, no guaruntee that this is a Xerces Document object.
This object is accessed without any locking from the following static
methods:
* split(String str, String pattern)
* tokenize(String toTokenize, String delims)
The methods invoked on the Document object are:
* Element org.w3c.dom.Document.createElement(String)
* Text org.w3c.dom.Document.createTextNode(String)
What this means is that there may be multiple threads simultaneously
invoking the above methods on a single Document object.
Is this safe?
I cannot find any documentation on the subject of the thread-safety of
the Document methods listed above.
If these are not thread-safe, then perhaps a bug should be raised
against ExsltStrings?
In addition, the static member is initialized in a non-thread-safe
manner. However, due to the way the resulting object is used I do not
think that any race condition can result. The worst that can happen is
that multiple Document objects are created, only one of which is then
cached for later use. I think this is probably not worth fixing [though
might be worth adding a comment about].
Regards,
Simon
