[ http://issues.apache.org/jira/browse/JDO-238?page=comments#action_12369545 ]
Martin Zaun commented on JDO-238: --------------------------------- Craig L Russell wrote: > > I think it's too late to add the requirement for thread-safety for > makePersistent of the same detachable instance by multiple threads. > > So I'd write a separate low priority JIRA for the thread-safe > makePersistent detachable and mark it for an unknown release. The rest > of the thread-safe cases should be good to go. OK. Created JDO-333 for testing thread-safety of operations on detached instances. Dropping test pm.makePersistent(shared detached PC instance) from ThreadSafe.java. > 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 > > 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
