"Newman, John W" <newma...@d3onc.com> wrote on 06/08/2011 01:24:38 PM:
> 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? I could imagine that might occur with the deferred DOM implementation. I believe the tables which store the data for the deferred nodes have a reference count on them. If multiple threads are hitting it, perhaps the ref count is hitting 0 and portions of those tables are being thrown away before the nodes which would be created from them are actually instantiated. I have never observed that myself, but all sorts of wacky things can happen if you haven't synchronized your code. The caches I've mentioned that get used internally when you traverse a NodeList have a tendency to jump around to other parent nodes in the DOM tree. So when you're "lucky" enough that the unsynchronized access isn't generating a NullPointerException you may find you're getting random data returned from other parts of the DOM (i.e. NodeLists which point to the children of some other node in the DOM). Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org
