[
https://issues.apache.org/jira/browse/XERCESJ-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Glavassevich resolved XERCESJ-1284.
-------------------------------------------
Resolution: Duplicate
Duplicate of XERCESJ-911.
This is not a bug; it's a usage error. Xerces DOM implementation is not
thread-safe [1] by design. Applications must synchronize their access to the
DOM even if they're just reading it. If you're looking for more info there
have been plenty of discussions concerning this topic on the Xerces-J mailing
lists over the years.
[1] http://xml.apache.org/xerces2-j/faq-dom.html#faq-1
> Race condition in dom traversal
> -------------------------------
>
> Key: XERCESJ-1284
> URL: https://issues.apache.org/jira/browse/XERCESJ-1284
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (Level 3 Core)
> Affects Versions: 2.9.1
> Environment: Windows XP running java 1.6 and 1.5.
> Reporter: Bob Miller
>
> After a parse an xml document into a dom tree using a single thread I create
> multiple threads to traverse the tree and read data (no updates). I have
> found a race condition involving nodeListGetLength in ParentNode and
> getNodeListCache in CoreDocumentImpl. The problem lies in the fact that when
> you free your fNodeListCache you can still keep using it, with the
> expectation that when your cache object is reallocated that it is removed
> from you. The race works as such. Imagine two threads T1 and T2. T1 has
> just started executing nodeListGetLength and has a non null fNodeListCache
> and T2 has just started executing CoreDocumentImpl and is about to give away
> the cache object that T1 uses.
> T1 passes if(fNodeListCache == null)
> T2 aqueires for itself fFreeNLCache and sets c.fOwner.fNodeListCache = null
> T1 checks fNodeListCache.fLength and fails on a null pointer error
> I am thinking that nodeListGetLength and getNodeListCache need to both
> synchronize on either the document or the node cache object. Synchronizing
> will have no effect on single thread access and should clean up multithreaded
> access. I am working on a test program that does not contain sensitive data
> and am also working on writing a patch.
> Does anyone have any suggestions or see anything I haven't?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
