sebb <seb...@gmail.com> wrote on 06/10/2011 11:26:27 AM: > 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.
Right. You need to synchronize access (read and write) to the entire DOM to have a correct program and think I've stressed that many times on this list, though suspect John is just looking for any work around at this point which provides relief for his application on the specific JVM / platform he's using which may in practice update the data on each thread more eagerly than required by the Java Memory Model and/or not reorder the writes in such a way that the program breaks. You're skating on thin ice if you're relying on this to work, but can understand folks trying it as a last resort. > 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 Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org
