Hi John, "Newman, John W" <newma...@d3onc.com> wrote on 06/09/2011 12:51:32 PM:
> Thanks Michael. That?s the response I?ve been waiting for. This > whole situation is really unfortunate, since it?s not even my code > that is missing the required locking, and the developers of that > faulting code have pretty decent justification for refusing to add > it. I?ll try to push back on them a little more for adding an > extension since this the xerces dom is really the default. I am not > the only one affected by this, anyone using the dom package in that > library without swapping the default implementation will run into > this. It?s just so rare and such a lucky situation that I?m > probably the first to notice it. > > There?s really nothing I can do besides some sort of wrapper or > proxy solution, a massive document pool, OR a larger re-architecting > effort <- . Maybe I can come up with something clean and quick, but > without a thread dump at the instant when this situation occurs, I > can?t get it under test, and can?t come up with the fix? > I guess my question is, if there?s a simple answer to this, what > specific methods of your library can cause volatility? Is it just > NodeList.length() and NodeList.item(), any specific others, or ALL > of them? Those two are always the ones I?ve already ran into and > have syncs around where my code is using them, it wasn?t too hard to > get some NPEs without the syncs. But without them I never noticed > corrupt documents. There are other places where there are internal writes. For example we always defer creation of the Text node child of an Attribute. Not sure if anything bad can happen there if you don't synchronize, but if you always access the Attribute value with getValue() instead of getFirstChild() the Text node never needs to be created. I think there are parts of the DOM Level 2 Events implementation that aren't thread-safe. With the non-deferred DOM implementation NodeList.length() and NodeList.item() are certainly the most likely methods you'll run into trouble with if you don't synchronize. Since the caches underneath the NodeLists move around the DOM instance you need to synchronize on the same object. The Document node may be a good choice for that locking object. Oh... and NodeLists returned from Document.getElementsByTagName*() get constructed lazily so you need to synchronize over those NodeLists too. > Thanks again, I?m glad this has turned into a healthy discussion. Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org
