On 08/06/11 05:06, Michael Glavassevich wrote:
Hi John,
None of Xerces' DOM implementations are thread-safe, even the
non-deferred ones. This is true even for read operations. In
particular, the implementation of the NodeList methods (i.e. item()
and getLength()) are not thread-safe. These m
Chris Simmons wrote on 06/08/2011 04:05:51 AM:
> On 08/06/11 05:06, Michael Glavassevich wrote:
> >
> > Hi John,
> >
> > None of Xerces' DOM implementations are thread-safe, even the
> > non-deferred ones. This is true even for read operations. In
> > particular, the implementation of the NodeLis
As a reminder: The reasons the DOM was specified by the W3C as not being
theadsafe are twofold.
1) Performance would be significantly impacted by excess locking. (Since
we're talking about Xalan-J, notice that Java users have almost completely
given up use of the inherently threadsafe hash and
> Since we're talking about Xalan-J
We're talking about Xerces-J. :-)
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrgla...@ca.ibm.com
E-mail: mrgla...@apache.org
kesh...@us.ibm.com wrote on 06/08/2011 08:47:38 AM:
> As a reminder: The reasons the DOM was specified by the
> > Since we're talking about Xalan-J
> We're talking about Xerces-J. :-)
Thanks. "To avoid damage, engage mind before putting fingers in gear."
I think I should be talking about a cup of coffee right now.
(T-t-t-alking 'bout code generation... no, that's also Xalan.)
On 06/08/2011 04:05 AM, Chris Simmons wrote:
On 08/06/11 05:06, Michael Glavassevich wrote:
Hi John,
None of Xerces' DOM implementations are thread-safe, even the
non-deferred ones. This is true even for read operations. In
particular, the implementation of the NodeList methods (i.e. item()
>"What exactly is "high load" in your case? Is it number of users using your
>applications, number of threads sharing your objects or what?"
~100 users at the same time, a percentage of which are reading the same node
and slicing through its children.
>"This may be due to insufficient design w
On Wed, 8 Jun 2011 13:59:15 +
"Newman, John W" wrote:
"What exactly is "high load" in your case? Is it number of users using your
applications, number of threads sharing your objects or what?"
~100 users at the same time, a percentage of which are reading the same node
and slicing throug
"Jacob Kjome" wrote on 06/08/2011 12:41:57 PM:
> On Wed, 8 Jun 2011 13:59:15 +
> "Newman, John W" wrote:
> >>"What exactly is "high load" in your case? Is it number of users using
your
> >>applications, number of threads sharing your objects or what?"
> >
> > ~100 users at the same time, a
I've thought about document pooling but I don't think that's very scalable.
These elements themselves are about 500k, the document has about 20 of these
elements. And I have ~16 organizations each with their own document. We're
already using enough ram to run this, I'd rather not have to set
On Wed, Jun 8, 2011 at 7:29 PM, Newman, John W wrote:
>
> ~100 users at the same time, a percentage of which are reading the same node
> and slicing through its children.
It seems, that all your users are concurrently accessing an in-memory
DOM tree for read access, and it seems that non thread-
11 matches
Mail list logo
