openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-63) Better pessimistic lock support for DB2 v8.2+
Date Mon, 06 Nov 2006 23:58:37 GMT
    [ http://issues.apache.org/jira/browse/OPENJPA-63?page=comments#action_12447595 ] 
            
Kevin Sutter commented on OPENJPA-63:
-------------------------------------

A couple of items with this issue...

o  Using the SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax for all forUpdateClause
usages may be too much.  One thing is that we may not need or want exclusive locks.  Update
locks would probably be sufficient.  Should this be configurable?

o  Along the same lines, what about the isolation level?  Besides, the "with rs", we could
specify "with cs", "with ur", or "with rr".  RS and RR levels allow for the lock clause, the
CS and UR levels do not.  So, here again, it looks like it should be configurable.  Or, at
least determined at runtime based on the isolation level.

o  Even for the optimistic locking case, the use of the "for read only" clause may be good
for performance reasons on DB2.

o  If we could determine a solid generic clause that would help your specific case, then I
would be more in favor of modifying the DB2 Dictionary.  For example, if "for read only" by
itself would suffice, then I would be okay with using that for the forUpdateClause.  But,
if that would not provide enough isolation and locking facilities for your scenarion, then
we might have to wait for a more generic solution.

o  By accident, I attempted to run with your changes while running some other tests with WebSphere
and DB2, and I found that the test conditions may not be sufficient.  I was running with DB2
v8.2 and I got the following error:

DSRA8750W: The JDBC 3.0 method getDatabaseMajorVersion is not implemented on this JDBC Provider.

The trace showed the following datasource information:

[11/6/06 16:11:16:620 CST] 00000023 InternalDB2Da I   DSRA8203I: Database product name : DB2/NT
[11/6/06 16:11:16:640 CST] 00000023 InternalDB2Da I   DSRA8204I: Database product version
: 08.02.0004
[11/6/06 16:11:16:650 CST] 00000023 InternalDB2Da I   DSRA8205I: JDBC driver name  : IBM DB2
JDBC 2.0 Type 2
[11/6/06 16:11:16:660 CST] 00000023 InternalDB2Da I   DSRA8206I: JDBC driver version  : 08.02.0004
[11/6/06 16:11:16:670 CST] 00000023 WSRdbDataSour I   DSRA8208I: JDBC driver type  : 2

So, we might have to check for more than just the database major and minor versions.  This
might also depend on the JDBC driver type.  Not sure, I didn't check into that aspect of the
solution just yet.

Given these discussion items, I'm not comfortable taking the patch as is.  Igor, if you want
to evaluate these comments and create an alternate patch, I would be interested in checking
it out.  Thanks.

Kevin

> Better pessimistic lock support for DB2 v8.2+
> ---------------------------------------------
>
>                 Key: OPENJPA-63
>                 URL: http://issues.apache.org/jira/browse/OPENJPA-63
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: jdbc
>         Environment: IBM DB2 UDB v8.2 or later
>            Reporter: Igor Fedorenko
>         Attachments: db2-selectForUpdate.patch
>
>
> There is new SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax in DB2
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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message