Hi Michael,
Provided that your code is ensuring that only one thread is accessing the
DOM at a time (i.e. the whole structure, not just one node) you should be
fine.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [EMAIL PROTECTED]
E-mail: [EMAIL PROTECTED]
Michael
Michael Glavassevich 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 (even on d
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 interloc
>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 Mon, 13 Mar 2006, Michael Glavassevich wrote:
> [EMAIL PROTECTED] wrote on 03/07/2006 12:42:55 PM:
>
> > 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?
>
> No. For example, you will
[EMAIL PROTECTED] wrote on 03/07/2006 12:42:55 PM:
> 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?
No. For example, you will run into trouble with NodeLists. Internally they
cache the l
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
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
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 m
>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 transac
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 that traverse the DOM concurrently without
synchronization.
Is the
11 matches
Mail list logo
