openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Igor Fedorenko (JIRA)" <>
Subject [jira] Commented: (OPENJPA-63) Better pessimistic lock support for DB2 v8.2+
Date Thu, 09 Nov 2006 06:08:37 GMT
    [ ] 
Igor Fedorenko commented on OPENJPA-63:

I guess I have not explained the problem I was trying to solve, so let me do that before I
answer your specific questions.

Reading objects with ReadLockMode set to LockModeType.WRITE should create database locks necessary
to prevent other concurrent transactions from using the same data. Here is a couple of relevant
quotes from OpenJPA documentation: "pessimistic transactions generally lock the datastore
records they act on, preventing other concurrent transactions from using the same data" and
"PessimisticLockManager ... uses SELECT FOR UPDATE statements (or the database's equivalent)
to lock the database rows corresponding to locked objects". 

OpenJPA does NOT create any database locks for more complex SELECT statements (with MultipleTables,
InnerJoin or OuterJoin). So I am asking to change OpenJPA such that it would be possible to
prevent other concurrent transactions from using the same data with SELECT statements with
MultipleTables, InnerJoin or OuterJoin for DB2 versions that support this.

Now to your questions.

o EXCLUSIVE vs UPDATE locks. Exposing fine-grained lock levels supported by DB2 is not necessary
to solve this particular problem and should be tracked as a separate bugreport (if there is
a need to provide such support in OpenJPA). Using UPDATE locks does seem more appropriate
and I will provide updated patch.

o Use FOR READ ONLY with optimistic transactions. Indeed, this should be a separate enhancement
request. I will update the patch not to include this (potential) performance optimization.

o Different isolation levels. Exposing different isolation levels is not necessary to solve
this particular problem. For consistancy sake, I will update the patch to use the same isolation
level as used in AbstractDB2Dictionary.

o Solid generic clause. I believe that "WITH RR USE AND KEEP EXCLUSIVE LOCKS" is the solid
generic clause to address this particular locking problem. At very least it is much more generic
than the very limited "FOR UPDATE WITH RR" clause current in use by OpenJPA.

o Use of JDBC 3.0 methods. Judging by "IBM DB2 JDBC 2.0 Type 2" log message, you're using
old CLI DB2 JDBC which is not supported according to OpenJPA documentation (and is going to
be removed from DB2 soon, according to the rumors). I will update the patch to fall back to
current lock behaviour with JDBC 2.x and earlier drivers. I will test the patch with both
CLI and JCC drivers with 8.2 and 9.1 and mayby with 8.1 too (I think I still have it around

Hope this helps.

> Better pessimistic lock support for DB2 v8.2+
> ---------------------------------------------
>                 Key: OPENJPA-63
>                 URL:
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: jdbc
>         Environment: IBM DB2 UDB v8.2 or later
>            Reporter: Igor Fedorenko
>         Attachments: db2-selectForUpdate.patch
v8.2 and later that can be used to implement pessimistic locks for selects with multiple from
tables, subselects, inner/outer joins and so forth. I'll attach simple patch shortly.

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