"Jacob Kjome" <[email protected]> wrote on 06/08/2011 12:41:57 PM:
> On Wed, 8 Jun 2011 13:59:15 +0000 > "Newman, John W" <[email protected]> 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 thesame node > >and slicing through its children. > > > > > >>"This may be due to insufficient design within your application. > You need to > >>tell more about your application design and give us more specifics, for > >>anyone to reason about the failures." > > > > Well, insufficient design would be using this non thread-safe library in an > >application that is constantly multithreaded. =) My application is not > >modifying the element. I don't know what else to say besides: sql proc > >returns xml. Xml is parsed into DeferredElementImpl. Element is stored in > >ram for access. Pages read element to display children. Users > click through > >elements children and ultimately select a leaf node which gets written to > >table. When I have a number of users reading the element in a certain ways > >at certain times, the children just disappear. > > > > You could continue to store the DOM element in memory, but rather than having > everyone reading that DOM directly, for each request/thread you could clone > the element so each reader would have it's own DOM with no contention (except > for the cloning, which you may have to synchronize). 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. > Jake > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [email protected] E-mail: [email protected]
