Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 78298 invoked from network); 24 Feb 2006 22:43:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 24 Feb 2006 22:43:29 -0000 Received: (qmail 4716 invoked by uid 500); 24 Feb 2006 22:43:27 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 4545 invoked by uid 99); 24 Feb 2006 22:43:26 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Feb 2006 14:43:25 -0800 Received: from ajax.apache.org (ajax.apache.org [127.0.0.1]) by ajax.apache.org (Postfix) with ESMTP id 1DD49199 for ; Fri, 24 Feb 2006 23:42:56 +0100 (CET) Message-ID: <1647349778.1140820976119.JavaMail.jira@ajax.apache.org> Date: Fri, 24 Feb 2006 23:42:52 +0100 (CET) From: "Craig Russell (JIRA)" To: jdo-dev@db.apache.org Subject: [jira] Updated: (JDO-238) Timing bug in TCK test case ThreadSafe In-Reply-To: <1732359610.1134124448353.JavaMail.jira@ajax.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/JDO-238?page=all ] Craig Russell updated JDO-238: ------------------------------ Fix Version: JDO 2 final (was: JDO 2 rc1) > 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