Re: Got the Issue

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: soumya.chatterjee@xxxxxxx
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                
       Business Solutions
                
       Outsourcing
____________________________________________

Prashant Reddy <prashant@xxxxxxxxxxx>

07/27/2007 10:50 AM

Please respond to
prashant@xxxxxxxxxxx

To	j-users@xxxxxxxxxxxxxxxxx
cc	Soumya Chatterjee <soumya.chatterjee@xxxxxxx>
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: soumya.chatterjee@xxxxxxx
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty. IT Services
> Business Solutions
> Outsourcing
> ____________________________________________ 
> 
> 
>  Michael Glavassevich
> <mrglavas@xxxxxxxxxx> 
> 
>  07/26/2007 09:51 AST
> 
> 
> 
>                    To
 
> 
> j-users@xxxxxxxxxxxxxxxxx
> 
>                    cc
 
> 
> Soumya Chatterjee
> <soumya.chatterjee@xxxxxxx>
> 
>                   bcc
 
> 
> 
> 
>               Subject  
> 
> Re: Got the Issue
> 
> 
> 
> 
> Prashant Reddy <prashant@xxxxxxxxxxx> 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: mrglavas@xxxxxxxxxx
> E-mail: mrglavas@xxxxxxxxxx
> 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