> Since we're talking about Xalan-J We're talking about Xerces-J. :-)
Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org kesh...@us.ibm.com wrote on 06/08/2011 08:47:38 AM: > As a reminder: The reasons the DOM was specified by the W3C as not > being theadsafe are twofold. > > 1) Performance would be significantly impacted by excess locking. > (Since we're talking about Xalan-J, notice that Java users have > almost completely given up use of the inherently threadsafe hash and > list classes that Java originally shipped with in favor of the newer > Collections classes for precisely that reason.) > > 2) DOM-level locking is almost never the right answer anyway. In > every case we (the DOM WG) looked at, when the user was talking > about threadsafety and the DOM what they really needed was locking > over a _sequence_ of operations -- a transaction -- and locking one > of those operations in isolation really would not have helped them. > This can only be properly addressed by higher-level locking in the > user's code... and if they're going to implement that level, having > locks on the DOM itself would be wasteful. > > (I was involved in some of that discussion. We really did consider > the alternative and actively rejected it.) > > > > I understand the conceptual attraction of having a locking DOM, but > it really wouldn't turn out to be useful. Applications need to > handle locking at a level which makes sense for the application. > > If you really do want to lock individual DOM actions, you can always > implement a class which provides a set of utility functions which > get passed a node and arguments and apply the latter to the former > under a lock. Of course you'd have to access that DOM _ONLY_ > through this tool for it to work, and as noted above it probably > won't actually accomplish what you need... but it would do what > you're asking for. > > ______________________________________ > "You build world of steel and stone > I build worlds of words alone > Skilled tradespeople, long years taught: > You shape matter; I shape thought." > (http://www.songworm.com/lyrics/songworm-parody/ShapesofShadow.html) > > > From: > > Michael Glavassevich <mrgla...@ca.ibm.com> > > To: > > j-users@xerces.apache.org > > Date: > > 06/08/2011 05:47 AM > > Subject: > > Re: DOM thread safety issues & disapearring children > > Chris Simmons <c...@corefiling.com> wrote on 06/08/2011 04:05:51 AM: > > > On 08/06/11 05:06, Michael Glavassevich wrote: > > > > > > Hi John, > > > > > > None of Xerces' DOM implementations are thread-safe, even the > > > non-deferred ones. This is true even for read operations. In > > > particular, the implementation of the NodeList methods (i.e. item() > > > and getLength()) are not thread-safe. These methods do some internal > > > writes to a cache which are necessary for good performance. There's a > > > longer explanation in the JIRA issue you found. > > > > > > Thanks. > > > > > > Michael Glavassevich > > > XML Parser Development > > > IBM Toronto Lab > > > E-mail: mrgla...@ca.ibm.com > > > E-mail: mrgla...@apache.org > > > > > Given that this keeps coming up, wouldn't it be prudent to fix this > > issue or have a separate DOM implementation that's read thread-safe? > > > > Would it really be that difficult? > > More time has passed but the answer [1] is still the same. > > Plus if you're expecting your code to work [2] with any DOM > implementation (not just a specific one you've locked yourself into) > you need to synchronize anyway. > > > Chris Simmons. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > > For additional commands, e-mail: j-users-h...@xerces.apache.org > > Thanks. > > [1] http://markmail.org/message/s7aniecyk4kwckdg > [2] http://markmail.org/message/jserv2iaeivutuuk > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: mrgla...@ca.ibm.com > E-mail: mrgla...@apache.org
