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 tree has been loaded into memory. Thread safety is only required if I am doing 'write' with one thread and 'read' with the other at the same time, which I am not doing in this scenario.
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. Is that possible? Just a guess. Please forgive me if I don't have enough understanding of the xerces DOM impl, but logically speaking, thread safety problem should not arise from a pure 'read' action. Cheers, Herry On 9 May 2002, at 23:44, Andy Clark wrote: > 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 > people that want to access the DOM from multiple threads. > Therefore, you are required to add the appropriate locks > to your application code. > > -- > Andy Clark * [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
