Michael Glavassevich mrglavas at ca.ibm.com writes:
No. For example, you will run into trouble with NodeLists. Internally they
cache the length and previously accessed position to improve the
performance of calls to getLength() and item(i). Invoking these methods
from multiple threads
Would it work if length and previously accessed position were stored in
ThreadLocal variables?
Don't go there. You're starting to talk about imparing performance for all
users to protect a few who really should be coding higher-level interlocks
in any case.
__
On Wed, 15 Mar 2006, Joseph Kesselman wrote:
Would it work if length and previously accessed position were stored in
ThreadLocal variables?
Don't go there. You're starting to talk about imparing performance for all
users to protect a few who really should be coding higher-level interlocks
in
The FAQ[1], declares xerces DOM implementation is not thread safe.
Most DOMs are not threadsafe, as the DOM REC points out.
Threadsafety at such a low level of a system tends to be expensive and
redundant, and often insufficient since what you're concerned about is
safety over a complete
Prashant [EMAIL PROTECTED] wrote on 03/07/2006
12:11:52 AM:
Hello:
The FAQ[1], declares xerces DOM implementation is not thread safe.
I
guess this is because of the Deferred DOM implementation.
I have in fact observed runtime exceptions[2] with xerces 2.7, 2.8
when
accessing methods
If no nodes are being altered by any thread, and
deferred-node-expansion is turned off, is the xerces DOM concurrently
accessible from multiple threads?
Jeff
On 3/7/06, Joseph Kesselman [EMAIL PROTECTED] wrote:
The FAQ[1], declares xerces DOM implementation is not thread safe.
Most DOMs are
Thank you for your response.
My post was under the assumption that the deferred-node expansion makes
the underlying data structures mutable' even though DOM is traversed in
a read-only way.
I understand that DOM REC does not talk about thread safety.
However it would be good if when the DOM
