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 Michael Glavassevich <mr...@ca.ibm.com> on 2007/07/24 15:57:59 UTC

Re: Got the Issue

Hi Soumya,

Xerces' DOM implementation isn't thread-safe. If you try to access the 
same DOM instance from multiple threads without synchronizing it you'll 
run into these problems. You either need to synchronize your code or 
create an instance of the DOM tree per thread. There's really no way 
around it.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Soumya Chatterjee <so...@tcs.com> wrote on 07/24/2007 09:42:08 
AM:
 
> Hi Michael, 
> 
> I found out the response from you regarding the "xerces DOM 
> concurrent access" and I think it is the same as our application in 
> the case.  http://spteam-lists.blogspot.com/2007/04/re-xerces-dom-
> concurrent-access-and.html 
> 
> By the way we were not getting the exception as frequently  in the 
> weblogic 7.1 ( JDK 1.3) when we are using the following Xerces.
> 
> But we are getting the exception in case of weblogic 9.1 much more 
> frequently which uses JDK1.5 and different version of Xerces. 
> 
> Synchronization is not an option in this case because there is a 
> huge performance issue here. Please let me know if any way we can 
> get read of this problem without using the Synchronization  block. 
> 
> Thanks,
> Soumya Chatterjee
> Tata Consultancy Services
> Mailto: soumya.chatterjee@tcs.com
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Outsourcing
> ____________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org


Re: Got the Issue

Posted by Prashant Reddy <pr...@pramati.com>.
On Tue, 2007-07-24 at 09:57 -0400, Michael Glavassevich wrote:
> Synchronization is not an option in this case because there is a 
> > huge performance issue here. Please let me know if any way we can 
> > get read of this problem without using the Synchronization  block. 
> >  

Is your use-case, creates the DOM once and reads multiple times in a
concurrent access ? 

The thing is that DOM traversal is not thread safe when accessed
concurrently even though there are *no* writes.

If your use case is similar (no writes to XML), it may be worth
implementing a higher level read-only(immutable) Data tree that reads
only once from the DOM/SAX. 

Of course you should measure the performance benefits before deploying
the solution. 
 
-- 

-Prashant

Don't upload, just share : www.dekoh.com


---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org


Re: Got the Issue

Posted by Soumya Chatterjee <so...@tcs.com>.
Hi Prashant,

We have found a suitable work around for the issue. We have replaced the 
NodeList implementation which surely is not  thread safe due to the 
caching mechanism built in it. 

We implemented "NodeList" using "Node"

The "for" loop is replaced by "while" loop as follows:-
First Element - Node's getFirstChild method
Next Element - Node's getNextSibling method
End of Iteration- Null is obtained when getNextSibling is used.

We have tested at our end and it worked fine. This might be a good 
alternative implementation for NodeList.

In this solution there is no  SLA impact , this solution is does not have 
any synchronization. 

Please suggest if you find any potential problem in this work around.

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



Prashant Reddy <pr...@pramati.com> 
07/25/2007 06:20 PM
Please respond to
prashant@pramati.com


To
j-users@xerces.apache.org
cc
Soumya Chatterjee <so...@tcs.com>
Subject
Re: Got the Issue






On Wed, 2007-07-25 at 11:58 +0530, Soumya Chatterjee wrote:
> 
> Hi Michael, 
> 
> Do you think SAX is a good alternative for the DOM in this case. We
> can migrate the parsing mechanism to SAX if there is no thread safe
> issue in SAX parser. 

SAX will help you build custom Data model for the XML it is parsing.
Usually SAX parsing of XML file is done only once (inside a method) to
construct the Data model. It is *not* a good idea to start a SAX parser
every time you would like to read something from the XML. (if thats what
you were hinting at in your question above)

You could think of DOM as a "generic" Data model that works for all
XMLs. While using DOM every thing is a Node/Element/Text Node and you
lose out on type safety and domain friendliness a custom Data model
would offer.

Consider the proverbial purchase order xml[1] for example:
You could walk this XML with SAX parser and construct Data model like 

Class PurchaseOrder {
Address getShippingAddress();
Address getBillingAddress();
List<Item> getItemsOrdered();
String getComment();
} //Notice there are not setters 

Where if you were to make DOM of the same XML, you would have to walk 
NodeList list =  purchaseOrderNode.getChildNodes(); //This is not thread
safe

Now is it a good alternative to DOM ?

The answer would depend as always on your use-cases. An immutable Data
object is as thread safe as it can get. And if you are accesses to XML
are read only, constructing a Data model from SAX parsing is worth
considering.

Hope this helps
-Prashant

[1] : http://www.w3.org/TR/xmlschema-0/#po.xml
PS: While you are at exploring options, you could also give JAXB a look
see.
> 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/24/2007 07:27 PM 
> 
> 
>                To
> Soumya Chatterjee
> <so...@tcs.com> 
>                cc
> j-users@xerces.apache.org 
>           Subject
> Re: Got the Issue
> 
> 
> 
> 
> 
> 
> 
> 
> Hi Soumya,
> 
> Xerces' DOM implementation isn't thread-safe. If you try to access
> the 
> same DOM instance from multiple threads without synchronizing it
> you'll 
> run into these problems. You either need to synchronize your code or 
> create an instance of the DOM tree per thread. There's really no way 
> around it.
> 
> Thanks.
> 
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
> 
> Soumya Chatterjee <so...@tcs.com> wrote on 07/24/2007
> 09:42:08 
> AM:
> 
> > Hi Michael, 
> > 
> > I found out the response from you regarding the "xerces DOM 
> > concurrent access" and I think it is the same as our application in 
> > the case.  http://spteam-lists.blogspot.com/2007/04/re-xerces-dom-
> > concurrent-access-and.html 
> > 
> > By the way we were not getting the exception as frequently  in the 
> > weblogic 7.1 ( JDK 1.3) when we are using the following Xerces.
> > 
> > But we are getting the exception in case of weblogic 9.1 much more 
> > frequently which uses JDK1.5 and different version of Xerces. 
> > 
> > Synchronization is not an option in this case because there is a 
> > huge performance issue here. Please let me know if any way we can 
> > get read of this problem without using the Synchronization  block. 
> > 
> > Thanks,
> > Soumya Chatterjee
> > Tata Consultancy Services
> > Mailto: soumya.chatterjee@tcs.com
> > Website: http://www.tcs.com
> > ____________________________________________
> > Experience certainty.        IT Services
> >                        Business Solutions
> >                        Outsourcing
> > ____________________________________________
> 
> ForwardSourceID:NT00009A82 
> =====-----=====-----=====
> 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:NT00009B6E 
=====-----=====-----=====
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



Re: Got the Issue

Posted by Prashant Reddy <pr...@pramati.com>.
On Wed, 2007-07-25 at 11:58 +0530, Soumya Chatterjee wrote:
> 
> Hi Michael, 
> 
> Do you think SAX is a good alternative for the DOM in this case. We
> can migrate the parsing mechanism to SAX if there is no thread safe
> issue in SAX parser. 

SAX will help you build custom Data model for the XML it is parsing.
Usually SAX parsing of XML file is done only once (inside a method) to
construct the Data model. It is *not* a good idea to start a SAX parser
every time you would like to read something from the XML. (if thats what
you were hinting at in your question above)

You could think of DOM as a "generic" Data model that works for all
XMLs. While using DOM every thing is a Node/Element/Text Node and you
lose out on type safety and domain friendliness a custom Data model
would offer.

Consider the proverbial purchase order xml[1] for example:
You could walk this XML with SAX parser and construct Data model like 

Class PurchaseOrder {
Address getShippingAddress();
Address getBillingAddress();
List<Item> getItemsOrdered();
String getComment();
} //Notice there are not setters 

Where if you were to make DOM of the same XML, you would have to walk 
NodeList list =  purchaseOrderNode.getChildNodes(); //This is not thread
safe

Now is it a good alternative to DOM ?

The answer would depend as always on your use-cases. An immutable Data
object is as thread safe as it can get. And if you are accesses to XML
are read only, constructing a Data model from SAX parsing is worth
considering.

Hope this helps
-Prashant

[1] : http://www.w3.org/TR/xmlschema-0/#po.xml
PS: While you are at exploring options, you could also give JAXB a look
see.
> 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/24/2007 07:27 PM 
> 
> 
>                To
> Soumya Chatterjee
> <so...@tcs.com> 
>                cc
> j-users@xerces.apache.org 
>           Subject
> Re: Got the Issue
> 
> 
> 
> 
> 
> 
> 
> 
> Hi Soumya,
> 
> Xerces' DOM implementation isn't thread-safe. If you try to access
> the 
> same DOM instance from multiple threads without synchronizing it
> you'll 
> run into these problems. You either need to synchronize your code or 
> create an instance of the DOM tree per thread. There's really no way 
> around it.
> 
> Thanks.
> 
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
> 
> Soumya Chatterjee <so...@tcs.com> wrote on 07/24/2007
> 09:42:08 
> AM:
> 
> > Hi Michael, 
> > 
> > I found out the response from you regarding the "xerces DOM 
> > concurrent access" and I think it is the same as our application in 
> > the case.  http://spteam-lists.blogspot.com/2007/04/re-xerces-dom-
> > concurrent-access-and.html 
> > 
> > By the way we were not getting the exception as frequently  in the 
> > weblogic 7.1 ( JDK 1.3) when we are using the following Xerces.
> > 
> > But we are getting the exception in case of weblogic 9.1 much more 
> > frequently which uses JDK1.5 and different version of Xerces. 
> > 
> > Synchronization is not an option in this case because there is a 
> > huge performance issue here. Please let me know if any way we can 
> > get read of this problem without using the Synchronization  block. 
> > 
> > Thanks,
> > Soumya Chatterjee
> > Tata Consultancy Services
> > Mailto: soumya.chatterjee@tcs.com
> > Website: http://www.tcs.com
> > ____________________________________________
> > Experience certainty.        IT Services
> >                        Business Solutions
> >                        Outsourcing
> > ____________________________________________
> 
> ForwardSourceID:NT00009A82     
> =====-----=====-----=====
> 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: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org


Re: Got the Issue

Posted by ke...@us.ibm.com.
http://www.w3.org/DOM/faq.html#SAXandDOM

______________________________________
"... 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)

Re: Got the Issue

Posted by Soumya Chatterjee <so...@tcs.com>.
Hi Michael,

Do you think SAX is a good alternative for the DOM in this case. We can 
migrate the parsing mechanism to SAX if there is no thread safe issue in 
SAX parser.

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/24/2007 07:27 PM

To
Soumya Chatterjee <so...@tcs.com>
cc
j-users@xerces.apache.org
Subject
Re: Got the Issue






Hi Soumya,

Xerces' DOM implementation isn't thread-safe. If you try to access the 
same DOM instance from multiple threads without synchronizing it you'll 
run into these problems. You either need to synchronize your code or 
create an instance of the DOM tree per thread. There's really no way 
around it.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Soumya Chatterjee <so...@tcs.com> wrote on 07/24/2007 09:42:08 

AM:
 
> Hi Michael, 
> 
> I found out the response from you regarding the "xerces DOM 
> concurrent access" and I think it is the same as our application in 
> the case.  http://spteam-lists.blogspot.com/2007/04/re-xerces-dom-
> concurrent-access-and.html 
> 
> By the way we were not getting the exception as frequently  in the 
> weblogic 7.1 ( JDK 1.3) when we are using the following Xerces.
> 
> But we are getting the exception in case of weblogic 9.1 much more 
> frequently which uses JDK1.5 and different version of Xerces. 
> 
> Synchronization is not an option in this case because there is a 
> huge performance issue here. Please let me know if any way we can 
> get read of this problem without using the Synchronization  block. 
> 
> Thanks,
> Soumya Chatterjee
> Tata Consultancy Services
> Mailto: soumya.chatterjee@tcs.com
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Outsourcing
> ____________________________________________

ForwardSourceID:NT00009A82 
=====-----=====-----=====
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



Resolve the Issue

Posted by Soumya Chatterjee <so...@tcs.com>.
Hi Michael,

We have found a suitable work around for the issue. We have replaced the 
NodeList implementation which surely is not  thread safe due to the 
caching mechanism built in it. 

We implemented "NodeList" using "Node"

The "for" loop is replaced by "while" loop as follows:-
First Element - Node's getFirstChild method
Next Element - Node's getNextSibling method
End of Iteration- Null is obtained when getNextSibling is used.

We have tested at our end and it worked fine. This might be a good 
alternative implementation for NodeList.

In this solution there is no  SLA impact , this solution is does not have 
any synchronization. 

Please suggest if you find any potential problem in this work around.

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/24/2007 07:27 PM

To
Soumya Chatterjee <so...@tcs.com>
cc
j-users@xerces.apache.org
Subject
Re: Got the Issue






Hi Soumya,

Xerces' DOM implementation isn't thread-safe. If you try to access the 
same DOM instance from multiple threads without synchronizing it you'll 
run into these problems. You either need to synchronize your code or 
create an instance of the DOM tree per thread. There's really no way 
around it.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Soumya Chatterjee <so...@tcs.com> wrote on 07/24/2007 09:42:08 

AM:
 
> Hi Michael, 
> 
> I found out the response from you regarding the "xerces DOM 
> concurrent access" and I think it is the same as our application in 
> the case.  http://spteam-lists.blogspot.com/2007/04/re-xerces-dom-
> concurrent-access-and.html 
> 
> By the way we were not getting the exception as frequently  in the 
> weblogic 7.1 ( JDK 1.3) when we are using the following Xerces.
> 
> But we are getting the exception in case of weblogic 9.1 much more 
> frequently which uses JDK1.5 and different version of Xerces. 
> 
> Synchronization is not an option in this case because there is a 
> huge performance issue here. Please let me know if any way we can 
> get read of this problem without using the Synchronization  block. 
> 
> Thanks,
> Soumya Chatterjee
> Tata Consultancy Services
> Mailto: soumya.chatterjee@tcs.com
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Outsourcing
> ____________________________________________

ForwardSourceID:NT00009A82 
=====-----=====-----=====
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