DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6885>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6885 NodeImpl,ParentNode thread safety -- maybe a warning is in order? Summary: NodeImpl,ParentNode thread safety -- maybe a warning is in order? Product: Xerces-J Version: 1.4.4 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: DOM AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] NodeImpl implements NodeList so it can return itself from getChildNodes(). ParentNode implements a child node cache (I assume for performance). This combination results in problems in a multi-threaded application. Consider the following innocuous-looking code: NodeList list = node.getChildNodes(); int len = list.getLength(); for (int i = 0; i < len; i++) { Node item = list.item(i); // do something with item } This should be safe, because it should enumerate each child node exactly once. It also looks like it should be thread-safe, because it does not modify the structure, and each thread appears to get its own copy of the NodeList object. However, because ParentNode uses itself as the NodeList and has an internal cached child object, the two calling threads can conflict and get incorrect or null results. I'm not sure if you would consider this a bug. If the library is not supposed to be thread-safe, that's a design choice, but there is no mention of thread-safety in the documentation and this particular thread unsafety is caused by an implementation choice, it's not implicit in the calling code (because there is no mutation or intentional sharing of objects). I am happy to discuss this issue via e-mail. -- Aaron Goodisman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
