On 9 June 2011 17:51, Newman, John W <newma...@d3onc.com> wrote: > 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.
Even if writes are only performed by a single thread, it is still possible for a separate read-only thread to see inconsistent data. This is a consequence of the Java Memory Model, which allows threads to cache data for performance reasons. In the absence of the correct synch., the values written in one thread may never be seen by another thread, or may be seen in a different order. Both the writer and reader threads need to synchronise on the *same* lock to ensure that the updated data is published correctly. [There are some other ways of doing this, e.g. volatile variables] This visibility issue is entirely separate from the issues that can be caused by failing to lock the whole transaction. Passing mutable data between threads needs to be handled very carefully to ensure the data is safely published. [A very good book on the subject is Java Concurrency in Practice by Goetz, Peierls, Bloch and others] --------------------------------------------------------------------- To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
