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 setup a pool and keep growing the pool size as we add users, not very efficient to have copies of everything. If the documents were small snippets pooling would be fine, but I think they're a little too big to scale like that. I'll keep that in my pocket as a last resort kind of thing.
So do you think the children disappearing is caused by unsafe state? Have you ever seen this before and know how to reproduce it in a test? Or is there no way two threads would drop the children and I've got something else going on? From: Michael Glavassevich [mailto:[email protected]] Sent: Wednesday, June 08, 2011 1:11 PM To: [email protected] Subject: Re: DOM thread safety issues & disapearring children "Jacob Kjome" <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> > For additional commands, e-mail: > [email protected]<mailto:[email protected]> Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [email protected]<mailto:[email protected]> E-mail: [email protected]<mailto:[email protected]>
