[
http://issues.apache.org/jira/browse/JDO-238?page=comments#action_12365901 ]
Martin Zaun commented on JDO-238:
---------------------------------
The barrier class is likely to be used in other TCK tests, I'm therefore
putting it into:
tck20/src/java/org/apache/jdo/tck/util and
tck11/test/java/org/apache/jdo/tck/util.
Reviewing the ThreadSafe test class with Craig, we'd like it to be extended to
test 2 thread-safety aspects by 4 tests:
1) Thread-Safety of PersistenceManagerFactory.getPersistenceManager():
- pm=pmf.getPM(), barrier, pm.close()
- pm=pmf.getPM(), pm.makePersistent(private PC instance), barrier,
pm.close()
No exceptions must occur.
2) Thread-Safety of PersistenceManager.makePersistent() on non-managed
instances:
- pm.makePersistent(shared transient PC instance), barrier, pm.close()
- pm.makePersistent(shared detached PC instance), barrier, pm.close()
Only one thread must succeed; all others must throw exactly a
JDOUserException.
We don't intend to test concurrency within in a transaction (shared PM/Tx) at
this time.
> 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
