Herry wrote:
> so if I do require thread safety for my application,
> what are the possible solutions (at least as far as
> xerces is concern). Will traversing the entire tree
> during the initialisation stage solve the problem?
You can synchronize on the document but then this would
then "lock" t
Hi,
so if I do require thread safety for my application,
what are the possible solutions (at least as far as
xerces is concern). Will traversing the entire tree
during the initialisation stage solve the problem?
Thanks.
Cheers,
Herry.
--- Andy Clark <[EMAIL PROTECTED]> wrote: > Herry Koh
wrote:
Herry Koh wrote:
> thanks for the reply. So if I want to have concurrent access to the
> DOM, I guess one way to do it will be to disable the Deferred
> feature. The way to do it is clearly described in the Xerces docs,
You're missing the entire point. Please re-read Elena's
post because she hits
Hi,
thanks for the reply. So if I want to have concurrent access to the
DOM, I guess one way to do it will be to disable the Deferred
feature. The way to do it is clearly described in the Xerces docs,
but it advices developers to use xerces's DOMParser class. Is it
not possible to use the Docum
Herry Koh wrote:
> apologies if I didn't make myself clear the last mail.
> By 'access' I mean just to *read* the leaf nodes of the DOM tree. In
> this scenario, I believe there is no need for thread safety.
Your assumption is incorrect. DOM is just a set of interfaces and
interfaces do not defin
Hi,
from my testing, I no longer believe that the problem
lies with the DeferredDOM implementation. I am seeing
the same NullPointerException right in the middle of
my test, where all the leaf nodes should already have
been loaded by previous tests.
To recap (since I noticed that my original mail
Yes, I think for the scenario of concurrent access, I should turn off
the deferred feature. Will try it out and let you know.
Thanks
Cheers,
Herry
On 9 May 2002, at 9:37, Christopher Ebert wrote:
>
> Hi Herry,
>
>
> I suspect this has something to do with the DeferredDOM impl,
> per
Hi Herry,
I suspect this has something to do with the DeferredDOM impl,
perhaps, while one thread is accessing the leaf node for the first
time, another thread came in, thought that the leaf node has
already been access and attempts to retrieve the values, resulting
in NULL pointer.
Hi
apologies if I didn't make myself clear the last mail.
By 'access' I mean just to *read* the leaf nodes of the DOM tree. In
this scenario, I believe there is no need for thread safety. The error I
wrote occurred when I am doing thousands of pure 'read' operations
concurrently, after the DOM t
Herry wrote:
> Having created a DOM tree, I created a test case that
> simulates 1100 threads access to a DOM tree, each
The DOM implementation is *not* designed to be thread-safe
for performance reasons. There is no reason to penalize
*everyone* for the overhead of synchronization for those
peopl
Hi,
I have an application that requires simultaneous
access of the DOM tree.
Having created a DOM tree, I created a test case that
simulates 1100 threads access to a DOM tree, each
thread searching the DOM tree 15 times at 3 leaf
nodes.
The DOM tree was pre-loaded into memory before the
test was ru
11 matches
Mail list logo
