[prev in list] [next in list] [prev in thread] [next in thread]
List: xerces-j-user
Subject: Re: DOM thread safety issues & disapearring children
From: Michael Glavassevich <mrglavas () ca ! ibm ! com>
Date: 2011-06-10 15:52:11
Message-ID: OFA05A1C71.8323A3BE-ON852578AB.0055A42F-852578AB.00572E89 () ca ! ibm ! com
[Download RAW message or body]
sebb <sebbaz@gmail.com> wrote on 06/10/2011 11:26:27 AM:
> On 9 June 2011 17:51, Newman, John W <newmanjw@d3onc.com> wrote:
> > Thanks Michael.=A0 That?s the response I?ve been waiting for.=A0 Th=
is whole
> > situation is really unfortunate, since it?s not even my code that i=
s
missing
> > the required locking, and the developers of that faulting code have=
pretty
> > decent justification for refusing to add it.=A0 I?ll try to push ba=
ck on
them
> > a little more for adding an extension since this the xerces dom is
really
> > the default.=A0 I am not the only one affected by this, anyone usin=
g the
dom
> > package in that library without swapping the default implementation=
will run
> > into this.=A0 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 pro=
xy
> > solution, a massive document pool, OR a larger re-architecting effo=
rt
<- .
> > 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 unde=
r
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?=A0 Is it just
NodeList.length()
> > and NodeList.item(), any specific others, or ALL of them?=A0 =A0=A0=
Those two
are
> > always the ones I?ve already ran into and have syncs around where m=
y
code is
> > using them, it wasn?t too hard to get some NPEs without the syncs.=A0=
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 threa=
d
> 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 DO=
M 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 p=
oint
which provides relief for his application on the specific JVM / platfor=
m
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 ic=
e 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 b=
e
> 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-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org=
[Attachment #3 (text/html)]
<html><body>
<p><tt>sebb <sebbaz@gmail.com> wrote on 06/10/2011 11:26:27 AM:<b=
r>
<br>
> On 9 June 2011 17:51, Newman, John W <newmanjw@d3onc.com> wr=
ote:<br>
> > Thanks Michael.=A0 That’s the response I’ve been =
waiting for.=A0 This whole<br>
> > situation is really unfortunate, since it’s not even my=
code that is missing<br>
> > the required locking, and the developers of that faulting cod=
e have pretty<br>
> > decent justification for refusing to add it.=A0 I’ll tr=
y to push back on them<br>
> > a little more for adding an extension since this the xerces d=
om is really<br>
> > the default.=A0 I am not the only one affected by this, anyon=
e using the dom<br>
> > package in that library without swapping the default implemen=
tation will run<br>
> > into this.=A0 It’s just so rare and such a lucky situat=
ion that I’m probably<br>
> > the first to notice it.<br>
> ><br>
> ><br>
> ><br>
> > There’s really nothing I can do besides some sort of wr=
apper or proxy<br>
> > solution, a massive document pool, OR a larger re-architectin=
g effort <- .<br>
> > Maybe I can come up with something clean and quick, but witho=
ut a thread<br>
> > dump at the instant when this situation occurs, I can’t=
get it under test,<br>
> > and can’t come up with the fix…<br>
> ><br>
> > I guess my question is, if there’s a simple answer to t=
his, what specific<br>
> > methods of your library can cause volatility?=A0 Is it just N=
odeList.length()<br>
> > and NodeList.item(), any specific others, or ALL of them?=A0 =
=A0=A0Those two are<br>
> > always the ones I’ve already ran into and have syncs ar=
ound where my code is<br>
> > using them, it wasn’t too hard to get some NPEs without=
the syncs.=A0 But<br>
> > without them I never noticed corrupt documents.<br>
> <br>
> Even if writes are only performed by a single thread, it is still<=
br>
> possible for a separate read-only thread to see inconsistent data.=
<br>
> This is a consequence of the Java Memory Model, which allows threa=
ds<br>
> to cache data for performance reasons.<br>
> In the absence of the correct synch., the values written in one th=
read<br>
> may never be seen by another thread, or may be seen in a different=
<br>
> order.<br>
</tt><br>
<tt>Right. You need to synchronize access (read and write) to the entir=
e 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 eac=
h 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 skati=
ng on thin ice if you're relying on this to work, but can understand fo=
lks trying it as a last resort.</tt><br>
<tt> <br>
> Both the writer and reader threads need to synchronise on the *sam=
e*<br>
> lock to ensure that the updated data is published correctly.<br>
> [There are some other ways of doing this, e.g. volatile variables]=
</tt><br>
<tt>><br>
> This visibility issue is entirely separate from the issues that ca=
n be<br>
> caused by failing to lock the whole transaction.<br>
> <br>
> Passing mutable data between threads needs to be handled very<br>
> carefully to ensure the data is safely published.<br>
> <br>
> [A very good book on the subject is Java Concurrency in Practice b=
y<br>
> Goetz, Peierls, Bloch and others]<br>
> <br>
> ------------------------------------------------------------------=
---<br>
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org<br>
> For additional commands, e-mail: j-users-help@xerces.apache.org</t=
t><br>
<br>
<tt>Thanks.</tt><br>
<br>
<tt>Michael Glavassevich<br>
XML Parser Development<br>
IBM Toronto Lab<br>
E-mail: mrglavas@ca.ibm.com</tt><br>
<tt>E-mail: mrglavas@apache.org</tt></body></html>=
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic