[ http://issues.apache.org/jira/browse/JDO-238?page=comments#action_12365397 ]
Martin Zaun commented on JDO-238: --------------------------------- The described issue is to be fixed by putting a 'barrier' synchronization before the pm.close(). There's a barrier utility that comes with JDK5 (in java.util.concurrent.CyclicBarrier), which cannot be used here to avoid introducing such a dependency. So, I've written a simple (and limited) barrier class that will do for the TCK tests. That barrier utility class is to be used from both, tck11's and tck20's org.apache.jdo.tck.api.persistencemanager.ThreadSafe tests. So, unless there's a common directory for shared utilities, I'm going to duplicate the barrier source into both, tck11's and tck20's, test classes. > 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 rc1 > > 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
