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 <[email protected]> To: [email protected] Date: 06/08/2011 05:47 AM Subject: Re: DOM thread safety issues & disapearring children Chris Simmons <[email protected]> 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: [email protected] > > E-mail: [email protected] > > > 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: [email protected] > For additional commands, e-mail: [email protected] Thanks. [1] http://markmail.org/message/s7aniecyk4kwckdg [2] http://markmail.org/message/jserv2iaeivutuuk Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [email protected] E-mail: [email protected]
