openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Albert Lee (JIRA)" <>
Subject [jira] Resolved: (OPENJPA-1609) PessimisticLockException instead of LockTimeoutException thrown on DB2V9 for ZOS
Date Wed, 07 Apr 2010 20:04:39 GMT


Albert Lee resolved OPENJPA-1609.

    Resolution: Fixed

> PessimisticLockException instead of LockTimeoutException thrown on DB2V9 for ZOS
> --------------------------------------------------------------------------------
>                 Key: OPENJPA-1609
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: DB2V91 on z/OS
>            Reporter: Jody Grassel
>            Assignee: Jody Grassel
>             Fix For: 2.0.0, 2.1.0
>         Attachments: OpenJPA-1609.patch
> I am observing the following problem while working with OpenJPA 2.x on DB2v91 for z/OS:
> When performing a EntityManager.find() with a lock timeout property set, I'm expecting
to receive a LockTimeoutException if my find operation fails to fetch the data from the database
within the specified timeout period.  Instead of getting the LockTimeoutException, I am getting
a PessimisticLockException -- an Exception that is considerably more severe then is expected.
> I looked at the stack trace, and found the following information:
> **Exception: Caught unexpected exception from find.
>     org.apache.openjpa.persistence.PessimisticLockException:Unable to obtain an object
lock on "null [java.lang.String]".
> FailedObject: 1 [org.apache.openjpa.util.IntId] [java.lang.String]
> 	at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(
> 	at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(
> 	at org.apache.openjpa.jdbc.sql.DB2Dictionary.newStoreException(
> 	at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(
> 	at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(
> 	at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(
> 	at
> 	at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(
> 	at org.apache.openjpa.kernel.ROPStoreManager.initialize(
> 	at org.apache.openjpa.kernel.BrokerImpl.initialize(
> 	at org.apache.openjpa.kernel.BrokerImpl.find(
> 	at org.apache.openjpa.kernel.BrokerImpl.find(
> 	at org.apache.openjpa.kernel.DelegatingBroker.find(
> 	at org.apache.openjpa.persistence.EntityManagerImpl.find(
> 	at suite.r80.base.jpaspec.entitymanager.testlogic.FindLockTestLogic.testScenarioL009(
> ...
> Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: DB2 SQL Error: SQLCODE=-913,
SQLSTATE=57033, SQLERRMC=00C9008E;00000304;DSN00292.JPA20EME.X'00000002'.X'01', DRIVER=3.57.91
{prepstmnt 2135785293 SELECT t0.version,, t1.version, t1.ENTITYALAZY_ID, t1.strData,
t0.strData FROM JPA20EMEntityA t0 LEFT OUTER JOIN JPA20EMEntityC t1 ON = t1.ENTITYA_ID
WHERE = ?  optimize for 1 row FOR READ ONLY WITH RR USE AND KEEP UPDATE LOCKS [params=(int)
1]} [code=-913, state=57033]
> 	at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(
> 	at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(
> 	at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$700(
> 	at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeQuery(
> 	at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeQuery(
> 	at org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeQuery(
> 	at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeQuery(
> 	at org.apache.openjpa.jdbc.sql.SelectImpl.executeQuery(
> 	at org.apache.openjpa.jdbc.sql.SelectImpl.execute(
> 	at
> 	at org.apache.openjpa.jdbc.sql.SelectImpl.execute(
> 	at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.getInitializeStateResult(
> 	at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(
> 	at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(
> 	... 43 more
> The problem is that OpenJPA does not properly process the combination of SQLCODE=-913,
SQLSTATE=57033, and SQLERRMC=00C9008E.
> The RedBook "DB2 for z/OS Stored Procedures: Through the CALL and Beyond" page 188 states:
> -913
> OF RESOURCE resource-type, AND RESOURCE NAME resource-name
> Explanation: The application was the victim in a deadlock or experienced a time-out.
> reason code indicates whether a deadlock or time-out occurred.
> SQLERRD(3) also contains the reason-code which indicates whether a deadlock or time-out

> occurred. The most common reason codes are:
> 00C90088 - deadlock 
> 00C9008E - time-out
> Response: The application should either commit or roll back to the previous COMMIT. Then,
> generally, the application should terminate. See message DSNT376I in DB2 UDB for z/OS
> Version 8 Messages and Codes, GC18-7422, for possible ways to avoid future deadlocks
> time-outs.
> The error being reported by DB2V9 on zOS is "SQLCODE=-913, SQLSTATE=57033, SQLERRMC=00C9008E",
which indicates that
> the reason for the unsuccessful execution is a Timeout, not a Deadlock.  
> Presently, the DB2Dictionary.isFatalException() method does not support that combination.
> I've made a change to the isFatalException() method that considers that error combination,
and the expected LockTimeoutException now surfaces.  I will post the patch on to this JIRA
in a few minutes.

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

View raw message