Fair enough. I do realize there's almost never motiviation to do such difficult work without getting paid or any benefit to your own projects. I did checkout the trunk and walk through the code earlier this afternoon. I've got to say, it is a much larger project than I expected when I typed that [somewhat frustrated] last email. It is not going to be trivial. I apologize for my tone there, I did mean to delete some of that before sending and forgot. :-)
A threadsafe extension for reads could be done though, I need a bit of time to get more familiar and see the the internal state in debug. In the meantime it looks like i'm making OK progress patching the library that lacks the synchronization... But there's a voice in my head that says i'm just begging for a ton of deadlocks. I'm also beginning to actually consider a pooling solution in the interim, it would be the safest bet and just some easy spring xml changes... I also am going to fragment the one document with 18 elements into 18 individual documents with one element.. that way the pools would be much smaller, and even if userA's got corrupt it's not the total end of the world as userB and userC can continue on. ________________________________________ From: Michael Glavassevich [mrgla...@ca.ibm.com] Sent: Tuesday, July 19, 2011 7:52 PM To: j-users@xerces.apache.org Subject: RE: DOM thread safety issues & disapearring children Hi John, "Newman, John W" <newma...@d3onc.com> wrote on 07/19/2011 02:15:20 PM: > I’m not getting the reason why you cannot provide an extension that > syncs the internal writes just for the read only DOM methods. To > allow thread safe reads particular to the implementation I know I am > using. I do not expect arbitrary library swaps to work.. that is nonsense. > > Would it really be that hard: search for references to the internal > state, for each reference, is the reference from a ‘read only’ > method? No-> do nothing, we know writes will still be volatile; > Yes -> override the method in the new extension, putting a sync > block using the touched internal field as the mutex… > > performance should be fine, documents do not get corrupt from being > read twice, single threaded app guy doesn’t use it, everyone is happy. To quote myself from 2007: "... I think it's unlikely to happen for the same reasons for many things that don't happen in open source projects: limited resources which don't have enough interest (possibly in part because the community doesn't have enough interest) and/or time and/or capability to do the work." Setting aside opinions of whether this should be done or not, throughout the years no one has ever volunteered to attempt this work. As long as that stays the case that would be the greatest reason it wouldn't happen. Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
