You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Soumya Chatterjee <so...@tcs.com> on 2007/07/26 08:08:43 UTC

Resolution of the Issue

The NodeList implementation is not thread safe. When iterating through 
children of a particular node, the NodeList gets changed by another thread 
doing the same action. As a result I get a NullPointerException sometimes 
and some other times I get "wrong document error" when I try to append 
this clone a child node to a document. We can see the following links for 
that.

http://mail-archives.apache.org/mod_mbox/xerces-j-dev/200403.mbox/%3C20040316005859.22961.qmail@nagoya.betaversion.org%3E

http://issues.apache.org/bugzilla/show_bug.cgi?id=27687

The first implementation to access children of a node does not work.
    NodeList childList=root.getChildNodes();
    for (int i=0; i<childList.getLength(); i++)
    {
        // doing something here with "childList.item(i)"
    }
 

The second implementation to access children of a node works.
        Node currChildNode = root.getFirstChild();
        while(currChildNode != null)
        {
                // Do something here with the "currChildNode"
                currChildNode = currChildNode.getNextSibling();
        }

Thanks,
Soumya Chatterjee
Tata Consultancy Services
Mailto: soumya.chatterjee@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Outsourcing
____________________________________________



Michael Glavassevich <mr...@ca.ibm.com> 
07/25/2007 12:59 AM

To
j-users@xerces.apache.org
cc
Soumya Chatterjee <so...@tcs.com>
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: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

keshlam@us.ibm.com 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:NT00009A9E 
=====-----=====-----=====
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