On Fri, 2007-07-27 at 12:37 +0530, Soumya Chatterjee wrote:
>
> 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.
I agree that it is unfortunate, that that merely walking of node list
internally results in modification of data-structures (the cache you
mentioned). Micheal already mentioned in this thread that :
<quote>
"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()."
</quote>
In other words, This is a feature, not a bug :-)
Some part of DOM API may work well in concurrent access, like you
pointed out..But how would you arrive at which parts of API are OK to
access without synchronization ? Does the W3C spec say anything about
this ? There are DOM Level1, Level2 etc, revision to the spec.
Otherwise this behavior you have observed is subject to change for each
version and code assuming this, would be very difficult to maintain and
will not be portable. For example when you decide to deploy your app to
different version of Weblogic, mysterious things may being to
happen.(Like the incident you have already reported in your original
post)
What about writing a utility class that wraps the Xerces NodeList
implementations with your own NodeList that will behave according to
your expectations even in concurrent read access. Let your application's
code use this object instead of using the one xerces returns.
As per accepting the fix to NodeList, i will leave it committers to
xerces project decide that.
>
> 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 NodeListimplementation
> getLength()anditem(i)does caching but Nodeimplementation
> 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
>
>
--
-Prashant
Don't upload, just share : www.dekoh.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
