Re: Why DOM Parser is not thread safe? Please explain

John,

Aren't those distinct issues?  You're referring to thread safety of the DOM 
itself.  Karthik's question is about a DOM Parser.  I can understand why one 
might want to use the DOM across threads (though I also understand the reasons 
for the lack of thread safety), but I can't understand why one would expect a 
DOM Parser to be thread safe?

BTW, can you be more specific about where exactly you synchronized around the 
DOM API to make it thread safe?  This information could be very useful for 
others.

Anyway, it seems to me that Karthik might be sharing a DocumentBuilder across 
threads.  The code he provides calls a method 
"getDocumentBuilder(isValidating)", but he doesn't provide the implementation 
of that method.  I suggest he ensures that the DOM builder object he returns 
from that method isn't shared across threads.

BTW, Michael, regarding DOM thread safety, maybe you can clarify something for 
me?

In response [1] to my question about whether a cloning a shared master DOM 
would be thread-safe, you said...

"A cloned node has the same owner Document. Still not thread-safe.  Importing 
the Node into another DOM instance (i.e. different owner Document) should work 
though."

But in a later response [2], you referenced your own responses [3][4] in an 
older thread where you appear to state that cloning should work fine, as long 
as Xerces is the DOM implementation.  And, for my purposes, I can guarantee 
that Xerces is the ONLY DOM implementation I will use.

So, once and for all, is a cloned document, per servlet request, thread-safe?  
Or do I need to import the whole document rather than clone to completely 
"disconnect" it from the cached master DOM?  If so, how much more overhead, if 
any, does importing entail than cloning?


[1] 
http://mail-archives.apache.org/mod_mbox/xerces-j-users/201106.mbox/%3COF4131DFD0.6AD897A4-ON852578A9.005D5922-852578A9.005E65AA%40ca.ibm.com%3E
[2] 
http://mail-archives.apache.org/mod_mbox/xerces-j-users/201106.mbox/%3COFA17E2F96.2D497417-ON852578A9.003594B3-852578A9.0036902E%40ca.ibm.com%3E
[3] 
http://markmail.org/message/s7aniecyk4kwckdg#query:+page:1+mid:7fl65aw5rryyljtv+state:results
[4] http://markmail.org/message/jserv2iaeivutuuk


Jake

On Mon, 15 Oct 2012 13:49:24 +0000
 "Newman, John W" <[email protected]> wrote:
> I ran into the same issue last year, we had a pretty healthy discussion 
>about it here 
> http://mail-archives.apache.org/mod_mbox/xerces-j-users/201106.mbox/browser
> 
> Just a few synchronized(){} blocks around the DOM API and everything is 
>fine.  No easily noticeable drop in performance, though I haven't yet 
>measured, and if I did it would probably be noticeable.
> 
> I think most people still agree there should be a thread safe implementation 
>of the parser, but the authors of xerces were pretty clear that it isn't 
>going to happen...
> 
> -----Original Message-----
>From: [email protected] [mailto:[email protected]] 
> Sent: Friday, October 12, 2012 07:51
> To: [email protected]; [email protected]; 
>[email protected]
> Subject: Why DOM Parser is not thread safe? Please explain
> 
> 
> 
> Apache Team,
> 
> Major concern for us with DOM parser in multi thread environment. Can you 
>please review this and provide your inputs? Thanks.
> 
> OS: Sun Solaris 10
> Server: Websphere 6
> JDK: 1.4
> Xerces version: Xerces_Version_1_2_0
> Number of Daemon threads per JVM: 3
> 
> Scenario:
> 
> In our Production environment when 3 daemon threads run under a JVM.
> 
> When 3 similar type of XML messages gets parsed at same second
> (concurrently) under a JVM, we notice some attribute gets missed. We went 
>through net and found that DOM implementation is not guaranteed to be thread 
>safe. But question is why it is not thread safe? Which part can go wrong? 
>Please provide details.
> 
> 
> Below is the piece of code:
> 
> public Document parse(InputSource inputSource, boolean isValidating) throws 
>SAXException,IOException {
> 
>             if ( getEntityResolver() == null )
>                   throw new IllegalStateException("EnitityResolver is not 
>set");
> 
>             DocumentBuilder docBuilder = getDocumentBuilder(isValidating);
> 
>                   // parsing from input source
>             docBuilder.setEntityResolver(getEntityResolver());
>             docBuilder.setErrorHandler    (getErrorHandler());
> 
>             return docBuilder.parse(inputSource);
> 
>       }
> 
> Sample xml passed to this code is attached: sample_message.xml
> 
> (See attached file: sample_message.xml)
> 
> 
> 
> Thanks,
> karthik
> 
> 
> 
> This e-Mail may contain proprietary and confidential information and is sent 
>for the intended recipient(s) only.  If by an addressing or transmission 
>error this mail has been misdirected to you, you are requested to delete this 
>mail immediately. You are also hereby notified that any use, any form of 
>reproduction, dissemination, copying, disclosure, modification, distribution 
>and/or publication of this e-mail message, contents or its attachment other 
>than by its intended recipient/s is strictly prohibited.
> 
> Visit us at http://www.polarisFT.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
>For additional commands, e-mail: [email protected]
> 
>