openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey (JIRA)" <j...@apache.org>
Subject [jira] Updated: (OPENJPA-182) db2 update lock syntax WITH <isolation> USE AND KEEP UPDATE LOCKS
Date Wed, 04 Apr 2007 23:50:32 GMT

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

Patrick Linskey updated OPENJPA-182:
------------------------------------

    Attachment: OPENJPA-182.patch

For the sake of discussion, I've attached an alternate patch that uses a new JDBCFetchPlan.setIsolationLevel()
instead of a hint for isolation level, and uses JDBCFetchConfiguration.getReadLockLevel()
to determine whether or not to do a SELECT ... FOR UPDATE. 

If the read lock level is set to LockLevels.LEVEL_WRITE, then the FOR UPDATE is included;
if the read lock level is set to LockLevels.LEVEL_READ, then no FOR UPDATE is used. If the
read lock level is LockLevels.LEVEL_NONE, then the default behavior is used. (This is possibly
not the best use of LEVEL_NONE -- I'm not sure if LEVEL_NONE means 'default' or something
else. But for the purposes of demonstration, it seemed expedient to use it. Adding a new LEVEL_DEFAULT
constant might make more sense.)

Also, I directly reused the java.sql.Connection constants, which is possibly non-ideal; we
might want to discuss making our own constants. Or not.

So, in this model, if there were a test case for this stuff, I would have changed the test
case to do:

Query q = em.createQuery(...);
JDBCFetchPlan plan = (JDBCFetchPlan) ((OpenJPAQuery) query).getFetchPlan();
plan.setIsolationLevel(Connection.TRANSACTION_SERIALIZABLE);
plan.setReadLockMode(LockModeType.WRITE); // force a FOR UPDATE
List l = q.getResultList();

Note also that this model allows the isolation level and read lock mode to be configured on
the EM itself, for use in find() calls and relationship lookups, and as the default settings
for the fetch plans of queries created from the EM.

Finally, I replicated the logic in DB2Dictionary, but I noticed that sometimes the logic checked
for "serializable" and sometimes it checked for "read-uncommitted". I preserved these checks,
but was this intentional? I'm not all that clear about what the optimizations are, so just
wanted to ensure that that wasn't a typo.

> db2 update lock syntax  WITH <isolation> USE AND KEEP UPDATE LOCKS
> ------------------------------------------------------------------
>
>                 Key: OPENJPA-182
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-182
>             Project: OpenJPA
>          Issue Type: New Feature
>          Components: jdbc
>         Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux
>            Reporter: David Wisneski
>         Assigned To: David Wisneski
>         Attachments: OPENJPA-182.patch, openJPA182.patch
>
>
> A while back we changed the syntax of update locking from FOR UPDATE OF  to  WITH RS
USE AND KEEP UPDATE LOCKS.   Additional changes are required because 
> 1.  if isolation=serializable is configured, then the syntax should be  WITH RR USE AND
KEEP UDPATE LOCKS
> 2.  when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND KEEP EXCLUSIVE
LOCKS  or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 only supports read or exclusive
locks. 
> 3.  DB2 supports both a FETCH FIRST  ROWS and update LOCKS clauses.
> So we change supportsLockingWithSelectRange = true in the AbstractDB2Dictionary class
and change the DB2Dictionary to append the correct LOCKS syntax depending on vendor, release
and isolation level.

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


Mime
View raw message