Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <248060570.265271268660667271.JavaMail.jira@brutus.apache.org>
Date: Mon, 15 Mar 2010 13:44:27 +0000 (UTC)
From: "Donald Woods (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Updated: (OPENJPA-991) Implement LockTimeout using db
 specific server-side lock timeout feature
In-Reply-To: <615234575.1237494710669.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/OPENJPA-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Donald Woods updated OPENJPA-991:
---------------------------------

    Fix Version/s:     (was: 2.0.0-beta)
                       (was: 1.2.2)
                   2.1.0

> Implement LockTimeout using db specific server-side lock timeout feature
> ------------------------------------------------------------------------
>
>                 Key: OPENJPA-991
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-991
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: kernel
>    Affects Versions: 1.0.4, 1.1.1, 1.2.2, 1.3.0, 2.0.0
>            Reporter: Albert Lee
>             Fix For: 2.1.0
>
>
> This issue is originally reported by Donald Woods in OPENJPA-957.
> "Looks like the existing implementation (not defined in JPA 1.0 Spec and OpenJPA specific) is using setQueryTimeout() in PessimisticLockManager, which is a client side JDBC timeout function, while lock timeouts are implemented in the DB server. See -
> DB2 - http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/r0011874.htm
> MS SQL - http://msdn.microsoft.com/en-us/library/aa213032(SQL.80).aspx
> Derby - config property - http://db.apache.org/derby/docs/dev/devguide/cdevconcepts16400.html
> Oracle - LOCKWAIT on the connection or on the DB
> Also, the following discussion gives a good overview of the two and why apps should use both to handle unreliable network conditions -
> http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/95755534-bbef-4c2c-afa4-b80ca2a2c333/"
> This issue caused TestException.testThrowsOptimisticException to hang when run against DB2 because the default lock timeout is -1 on DB2, which means to wait forever. This test case will be disabled until the issue is resolved and re-enabled.
> Albert Lee.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.