[ http://issues.apache.org/jira/browse/JDO-238?page=comments#action_12369726 ]
Martin Zaun commented on JDO-238: --------------------------------- > 1. The thread count of 2 doesn't seem to be much of a test. How about 14 or > so? Having run my tests with a threadCount of 10, I was surprised to see that there's a reproducable deadlock happening with 20 threads (actually, with more than 16 threads, on my machine). There seems to be an issue with jpox: From a certain number on of open PMs, even if they don't have an active transaction anymore, any attempt to begin a transaction on other PMs results in an infinite wait. Filing a jpox bug. To have the TCK running, I'm checking in the ThreadSafe test with threadCount=10. > 2. The use of a local pmf should be restricted to where you need more than > the single PMF that most tests use. Rather, the pmf defined in JDO_Test can > be accessed directly without hiding it by the local pmf. Removed local pmf. > 3. The use of testXXX should be avoided as testXXX methods are special cases > for JUnit. Suggest calling the testConcurrent something like > runConcurrentThreads. Agreed. Renamed method to: runThreads(). > Timing bug in TCK test case ThreadSafe > -------------------------------------- > > Key: JDO-238 > URL: http://issues.apache.org/jira/browse/JDO-238 > Project: JDO > Type: Bug > Components: tck11, tck20 > Versions: JDO 2 beta > Reporter: Michael Bouschen > Assignee: Martin Zaun > Priority: Minor > Fix For: JDO 2 final > Attachments: ThreadSafe.java, ThreadSafe.java.diff > > The TCK test ThreadSafe runs multiple threads, where each thread tries to > persist the same pc instance using its own PM. The expected behavior is that > one thread succeeds persisting the pc instance and stores it at transaction > commit. All other threads should result in a JDOException because the pc > instance is already bound to a different PM. All threads close the PM at the > end. > Now, it might happen that the succeeding thread closes the PM before a > parallel thread tries to persist the pc instance. The behavior of > pm.makePersistence for a pc instance bound to a closed pm is not specified, > so it does not necessarily result in an exception. > The test case should be changed such that the succeeding thread waits for all > the other threads before closing the PM. Please note, the solution must be > robust enough to avoid a deadlock situation even if an erroneous JDO > implementation would allow multiple threads to succeed persisting the pc > instance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
