Thanks a lot for the clear explanation. I had already gone through the various forums and found out what is the reason behind the issue.
Just for my academic curiosity, I want to know why caching mechanism sometimes yields this error. Please let me know, at your convenient time, or guide me to the documentation about this caching mechanism implementation.
Thanks,
Soumya Chatterjee
Tata Consultancy Services
Mailto: [EMAIL PROTECTED]
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Outsourcing
____________________________________________
Michael Glavassevich <[EMAIL PROTECTED]>
07/24/2007 15:29 AST |
To |
j-users@xerces.apache.org |
cc |
Soumya Chatterjee <[EMAIL PROTECTED]> | |
bcc |
||
Subject |
Re: Got the Issue | |
The non-deferred DOM (yes it's still supported; it's the default impl for
an LSParser) isn't thread-safe for reads either. For instance, it caches
the last position accessed in a NodeList (returned from
Node.getChildNodes()) as well as its length. This is done for performance
reasons. Without it we would need to walk through the N-1 siblings to get
the Nth item in the list and would have to walk across all of the siblings
to get the length of the list. Due to the way the caching mechanism works,
concurrent reads of a NodeList can lead to the NPEs which Soumya is
getting or incorrect values being returned from item() or getLength().
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [EMAIL PROTECTED]
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote on 07/24/2007 02:54:01 PM:
> Per the W3C spec, the DOM API does not promise to support
> multithread access. Doing so would impose performance/implementation
> limitations on all applications, even single-threaded ones, which
> was considered undesirable. Also, in most cases what you really need
> is threadsafety at a much higher level than single DOM operations.
>
> In *some* (but not all) DOMs, you can get away with concurrent reads
> as long as nobody is altering the DOM. The Xerces "delayed DOM" is
> one which does _not_ promise to support that; if you tell Xerces to
> use the fully-preconstructed DOM implementation instead (do we still
> support it?) that may get you back on the air... but this is an
> implementation-specific hack and is not really good coding practice.
> It's better to put explicit thread handshaking into your application
> code where needed, via the use of appropriate semaphores and locks.
>
> ______________________________________
> "... Three things see no end: A loop with exit code done wrong,
> A semaphore untested, And the change that comes along. ..."
> -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish (http://www.ovff.
> org/pegasus/songs/threes-rev-11.html)
ForwardSourceID:NT00020C52
=====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
