"Jacob Kjome" <h...@visi.com> 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" <john.new...@viaoncology.com> 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: karthikeyan...@polarisft.com [mailto:karthikeyan...@polarisft.com ] > > Sent: Friday, October 12, 2012 07:51 > > To: j-users@xerces.apache.org; j-users-i...@xerces.apache.org; > >j-...@xerces.apache.org > > 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: j-users-unsubscr...@xerces.apache.org > >For additional commands, e-mail: j-users-h...@xerces.apache.org > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org Michael Glavassevich XML Technologies and WAS Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org
