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