Hi Prashant,
When we are taking about the thread safety that normally does not means
that there should also be Read synchronization. In other cases when you
say something is not thread safe that means it might get wrong values when
there are updates and reads at the same time in multi threaded
environment. But here what is happening is wrong because it is giving a
NullPointerException while reading in multi thread environment. By the way
it is not true that DOM implementation is not READ THREAD SAFE in totality
then it should not work in case of NODE implementation which is there
below in my mail. I think we need to understand that thread safe does not
mean it is a READ THREAD SAFE. Threading mechanism violates if that is
boils down to the Read synchronization.
If Xerces design choice is not be thread safe then please explain why it
does work when we implement through Node instead of NodeList. Please also
let me know where it is written that Node implementation is thread safe.
By the way Node is also not thread safe, but it does work because either
it does not do caching or it does know how to handle multiple reads.By the
way I have gone through the documentation and it is written that in
NodeList implementation getLength()and item(i) does caching but Node
implementation getFirstChild() and getNextSibling() does not do caching .
I think we need to accept that it is not desirable in any software that
read also needs to be synchronized due to some performance implementation
and caching where it is any way violating that performance criteria
because it is doing the read sequentially. It does not actually matter
who are using Xerces including ANT, Sun JDK, and several J2EE application
servers. but it remains a problem and if we over look this issue then
people need to do synchronization in Reading which any way will not
resolve there problem in multi threaded environment due to performance
issue. By the way many people think it is not worth to use the DOM but SAX
persor and one of the reason is this Read thread safety issue.
HOW THEN THIS WORKS IT DOM IS NOT THREAD SAFE.
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
____________________________________________
Prashant Reddy <[EMAIL PROTECTED]>
07/27/2007 10:50 AM
Please respond to
[EMAIL PROTECTED]
To
j-users@xerces.apache.org
cc
Soumya Chatterjee <[EMAIL PROTECTED]>
Subject
Re: Got the Issue
1. XML Spec does not mandate implementations of DOM to be thread safe.
2. Xerces implementation is not thread safe. This is a low level XML
parser implementation that allows users to build Data models, and it is
expected of the 'enterprise' software to build such models.
3. JAXP allows code to be agnostic of the XML parser implementation
chosen, allowing to replace with another parser implementation.
4. Using Xerces specific features will lock your application to xerces
parser (and worse a version of xerces). This is not a good idea
specially if your application is a J2EE application intended to be
deployed on disparate application servers which may ship different
implementation of parsers.
Given these facts, it is not a good idea to pursue the approach of
trying to fix NodeList implementation of Xerces.
Xerces design choice to not be thread safe does not in anyway reflect
the quality of the software. Xerces is infact JAXP complaint and widely
used parser implementation. Software such as ANT, Sun JDK, and several
J2EE application servers use Xerces.
-Prashant
On Thu, 2007-07-26 at 20:59 +0530, Soumya Chatterjee wrote:
> The issue I think is not that it fails multi threading environment in
> NodeList because the way it does the caching.
>
>
>
> If no one is changing any value of the DOM object and only reads from
> it then setting the following should work in NodeList implementation.
>
> docBuilderFactory.setAttribute(
http://apache.org/xml/features/dom/defer-node-expansion, Boolean.FALSE)
>
>
>
> But it does not work because the NullPointerException is noting to do
> with the multi threaded access but it is due to the way it does the
> caching. Now in the Node implementation when we use getFirstChild and
> getNextSibling, it is not doing any caching and resolved the issue. I
> still think that NodeList should not give a null pointer exception
> because that is not desirable in any enterprise architecture where
> multi threading and performance have no alternative.
>
>
>
> Please let me know if I am wrong in my analysis.
>
> 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/26/2007 09:51 AST
>
>
>
> To
>
> j-users@xerces.apache.org
>
> cc
>
> Soumya Chatterjee
> <[EMAIL PROTECTED]>
>
> bcc
>
>
>
> Subject
>
> Re: Got the Issue
>
>
>
>
> Prashant Reddy <[EMAIL PROTECTED]> wrote on 07/26/2007 02:19:05 AM:
>
> > Like someone else suggested earlier have you tried turning off the
> > Defered node expansion to see if you still face any problems ?
> >
> >
> > Try :
> > docBuilderFactory.setAttribute("http://apache.
> > org/xml/features/dom/defer-node-expansion", Boolean.FALSE);
> >
> > Be adviced that turning this feature off will mean your code (even
> if it
> > works) will have a semantic-lock in to behavior of Xerces XML
> parser.
>
> If you're relying on certain DOM operations being thread-safe you've
> already locked yourself in, perhaps to a specific version of Xerces.
> Your
> code may not work with other DOM implementations and there's no
> guarantee
> that it will work with future releases of Xerces (even the next bug
> fix
> release).
>
> > > http://issues.apache.org/bugzilla/show_bug.cgi?id=27687
> >
> > I am not sure fixing the parser to become thread-safe when it is
> already
> > declared to be not a goal is such a good idea. Besides there may be
> > other places in the xerces code where assumption of no concurrent
> access
> > may be made.
>
> Indeed there are. At the risk of encouraging folks to write more
> brittle
> code I won't list them here.
>
> > -Prashant
>
> Thanks.
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: [EMAIL PROTECTED]
> E-mail: [EMAIL PROTECTED]
> ForwardSourceID:NT00020E1A
> =====-----=====-----=====
> 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
>
>
--
-Prashant
Don't upload, just share : www.dekoh.com
ForwardSourceID:NT00009C9E
=====-----=====-----=====
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
