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/[EMAIL PROTECTED] 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: [EMAIL PROTECTED] Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Outsourcing ____________________________________________ Michael Glavassevich <[EMAIL PROTECTED]> 07/25/2007 12:59 AM To j-users@xerces.apache.org cc Soumya Chatterjee <[EMAIL PROTECTED]> 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: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
