Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
Message-ID: <18039047.1175156125147.JavaMail.jira@brutus>
Date: Thu, 29 Mar 2007 01:15:25 -0700 (PDT)
From: "Patrick Linskey (JIRA)" <jira@apache.org>
To: open-jpa-dev@incubator.apache.org
Subject: [jira] Commented: (OPENJPA-182) db2 update lock syntax  WITH
 <isolation> USE AND KEEP UPDATE LOCKS
In-Reply-To: <10767081.1174929812132.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Patrick Linskey commented on OPENJPA-182:
-----------------------------------------

Wow... that's a lot more DB2 locking knowledge than I've ever seen in one place. Neat.

Some comments on the patch:

1. How does the openjpa.hint.updateClause hint differ from the value of the forUpdate flag passed in to the DBDictionary call? It looks like the existing OpenJPA per-transaction read / write lock level configuration could be used instead.

2. Is openjpa.hint.isolationLevel really a hint, or more of a rule? Again, I have a hunch that maybe we could do something with the read / write lock levels, or maybe some other means of controlling isolation level. In any event, it seems like isolation level isn't really a hint, but rather is more of a rule.

3. You introduced a number of public boolean fields for determining what type of DB2 instance is being used. Based on code inspection, it looks like you expect that it should always be possible to automatically determine the type; maybe these should be private fields instead? We only have public fields in DBDictionaries for user-configurable settings. Also, since it looks like only one of the booleans can meaningfully be true, I'd rather see a single private db2ServerType field that will be set to one of several symbolic constant values. This will let you replace the if-else block with a switch block if you prefer that sort of thing, also.

> 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: 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.