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

"Jacob Kjome" <[email protected]> wrote on 15/10/2012 12:12:25 PM:

> 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 
wouldexpect 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."

You were talking about cloning elements in that e-mail and my statement 
was probably directly in response to that, taking what you said literally 
and not an intention to clone the entire DOM instance as a whole.

> 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?

It is with Xerces if the node you cloned was the Document node.
  
> 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?

Cloning a Document node is the same as creating a new document and (deep) 
importing all the immediate child of the other document. Whether you're 
cloning or importing it's going to create new objects.

> [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]
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]

Michael Glavassevich
XML Technologies and WAS Development
IBM Toronto Lab
E-mail: [email protected]
E-mail: [email protected]