Jim
Dennis Sosnoski wrote:
It doesn't matter that a singleton DocumentFactory is being used, because all that DocumentFactory does is call the constructor for the Element. The only time when thread safety becomes an issue for shared classes is when there is state information stored in the class. DocumentFactory doesn't appear to do this, except by way of the static QNameCache instance.
- Dennis
Jim Brain wrote:
In the case I have, we are doing:
public static Element doThis() {
Element e=DocumentHelper.createElement("Jim");
e.addElement("Fred");
return e;
}
According to Java rules, multiple threads calling doThis should get an instance of Element on the local heap, and no two threads are using the same Element. However, under the covers, the ELement are using a singleton documentFactory (createElement sets that up). I guess I could create my own documentFactory for each thread (threadlocal storage), but I hesitate to go there just yet.
Jim
Dennis Sosnoski wrote:
Actually, on looking at this in more detail it looks like the NamespaceCache already handles the multiple threads with separate documents case properly, with synchronized methods. QNameCache just needs the same type of change. I don't know why this was addressed in NamespaceCache but not in QNameCache - James, are you out there for comment?
- Dennis
Dennis Sosnoski wrote:
In the simple case where multiple threads are building separate documents simultaneously you only need to change the static data structures: QNameCache and NamespaceCache that I know of. Using non-threadsafe code for these static data structures is a true bug in the current dom4j implementation, and should be fixed.
If you actually want to support multiple threads accessing a writable document (even if only one is doing the writing) the problems go far beyond HashMap. You'd need to synchronize *all* calls (including read-only access calls to elements and such, since another thread could be modifying the data at the same time as your reader is accessing it). In order to avoid deadlock problems you'd probably want to use the document root object for all the synchronizations. The cleanest way of implementing this is by doing it in your own code, wrapping the dom4j calls with a synchronize on the document object.
- Dennis
David Hooker wrote:
I second this (or is it third?) also. I've seen some weird exceptions
coming out of DOM4J on SMP (multi-cpu) machines. While I can't
definitively blame Dom4J, it would at least lessen the risk in this
area.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:dom4j-dev-admin@;lists.sourceforge.net] On Behalf Of Brain, Jim
Sent: Tuesday, October 22, 2002 10:59 AM
To: 'David D. Lucas'; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Cc: Brain, Jim
Subject: [dom4j-dev] RE: Thread Safety
I also echo a need to resolve this. We are currently having this issue
in
production on a mission critical (probably everyone says that, but it is
an
app entry system for an insurance carrier, so I hope that qualifies)
application running on IBM OS/390 (ye old mainframe). Before I pull the
HashTable version, I'd like to hear what the longer term plans are,
since
there is a considerable ramp time on getting new cuts of code through
our
integration management process.
Jim
Jim Brain, [EMAIL PROTECTED]
"Researching tomorrow's decisions today."
(319) 369-2070 (work)
SYSTEMS ARCHITECT, ITS, AEGON FINANCIAL PARTNERS
-----Original Message-----
From: David D. Lucas [mailto:ddlucas@;lse.com] Sent: Tuesday, October 22, 2002 9:34 AM
To: [EMAIL PROTECTED];
[EMAIL PROTECTED]
Cc: Brain, Jim
Subject: Thread Safety
Sorry for the cross post, but I have not seen any feedback on the thread
safety issues. I have taken the stock CVS and changed all the HashMaps to Hashtables to get things to work in our server environment.
I would like to know what the long term direction is for thread safety and if anyone would like my changes?
Basically I took all the classes in org.dom4j.* and org.dom4j.tree.* and
changed them to use Hashtable. The methods out there with synchronization are probably no longer needed now that we have a Hashtable. I am looking at an alternative approach to keep the HashMap and performance without having thread related failures.
All this came from the QNameCache getting corrupted when two threads hit
it at the same time. It appears that one did a put while another did a get and resulted in a null coming back.
Please let me know what I should do next with the code. If you want I can post it or check it in (given access to development CVS).
Thanks in advance,
Dave
-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote
_______________________________________________
dom4j-dev mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dom4j-dev
-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote
_______________________________________________
dom4j-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dom4j-user
.
.
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
dom4j-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dom4j-user
