[
https://issues.apache.org/jira/browse/OPENJPA-991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688093#action_12688093
]
Albert Lee commented on OPENJPA-991:
------------------------------------
Oracle 11g lock timeout support in the
LOCK TABLE ..... IN lockmode MODE WAIT xsec clause pg 18-72
SELECT... .FOR UPDATE .... WAIT xsec clause pg 19-13
http://download.oracle.com/docs/cd/B28359_01/server.111/b28286.pdf
-----------------------------------
DB2 uses "SET CURRENT LOCK TIMEOUT = <secs>" for all statements on the current
connection.
-----------------------------------
Derby reference.
http://db.apache.org/derby/docs/10.1/ref/refderby.pdf
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY
Use the SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY system procedure to set or
delete the value of a property of the database on the current connection. If
"VALUE" is not null, then the property with key value "KEY" is set to "VALUE".
If "VALUE" is null, then the property with key value "KEY" is deleted from the
database property set.
Syntax
SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY(IN KEY VARCHAR(128),IN VALUE
VARCHAR(32672))
This procedure does not return any results.
JDBC example
Set the derby.locks.deadlockTimeout property to a value of 10:
CallableStatement cs = conn.prepareCall
("CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(?, ?)");
cs.setString(1, "derby.locks.deadlockTimeout");
cs.setString(2, "10");
cs.execute();
cs.close();
SQL example
Set the derby.locks.deadlockTimeout property to a value of 10:
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY
('derby.locks.deadlockTimeout', '10');
Derby 10.1 does not implement
• setQueryTimeout
Derby 10.2 has full support for Statement.setQueryTimeout()
> 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
>
> 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.
