db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Zaun (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JDO-238) Timing bug in TCK test case ThreadSafe
Date Thu, 09 Mar 2006 20:00:39 GMT
    [ 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:
For more information on JIRA, see:

View raw message