On 06/08/2011 04:05 AM, Chris Simmons wrote:
On 08/06/11 05:06, Michael Glavassevich wrote:
Hi John,
None of Xerces' DOM implementations are thread-safe, even the
non-deferred ones. This is true even for read operations. In
particular, the implementation of the NodeList methods (i.e. item()
and getLength()) are not thread-safe. These methods do some internal
writes to a cache which are necessary for good performance. There's a
longer explanation in the JIRA issue you found.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrgla...@ca.ibm.com
E-mail: mrgla...@apache.org
Given that this keeps coming up, wouldn't it be prudent to fix this
issue or have a separate DOM implementation that's read thread-safe?
Would it really be that difficult?
Chris Simmons.
Chris,
I'd think it's unlikely that multithreaded access to a DOM
implementation is the common workflow. Given the performance
characteristics of DOM i don't see why anyone would use it in a highly
multithreaded, performant environment. If this is the case, it would
make sense to marshal the DOM into some POJO framework, whether that is
JAXB or something. The performance for multithreaded reads is going to
smoke any DOM based implementation.
Therefore i don't see why synchronization would want to be added on top
of the DOM protocol, it would be recommending bad practices, in my mind.
dave
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org
For additional commands, e-mail: j-users-h...@xerces.apache.org
