Every Node in the Xerces DOM is also its child NodeList (i.e. node ==
node.getChildNodes()). You get the same object every time. If a single
thread is doing something like:
...
NodeList list = node.getChildNodes();
int length = list.getLength();
for (int i = 0; i < length; ++i) {
for (int j = length - 1; j >= 0; --j) {
Node nodeI = list.item(i);
Node nodeJ = list.item(j);
...
}
}
it's going to defeat the caching mechanism which was optimized for
sequential access. We'll end up walking back and forth through the
sibilings between i and j.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@xxxxxxxxxx
E-mail: mrglavas@xxxxxxxxxx
keshlam@xxxxxxxxxx wrote on 07/24/2007 03:54:16 PM:
> Right. I wouldn't expect nodelists to be threadsafe, but do we reuse
> nodelists, or would independent calls to retrieve the same nodelist
> return separate (non-entangled) objects?
>
> I would expect the latter, since there could be several nodelist
> accesses in progress at once even for a single thread.
>
> As I said, trying to use the DOM as if it was partly thread-safe is
> a cheat; you have to know exactly what you can and can't get away
> with. It's better to implement proper thread-locking in the application
code.
>
> ______________________________________
> "... Three things see no end: A loop with exit code done wrong,
> A semaphore untested, And the change that comes along. ..."
> -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish (http://www.ovff.
> org/pegasus/songs/threes-rev-11.html)
|
