[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486987
]
Abe White commented on OPENJPA-182:
-----------------------------------
What is setting the isolation level this way actually doing? For anything
other than DB2 right now, it looks like it doesn't do anything. And even for
DB2, it's unclear to me exactly what the isolation level hint is doing, and why
the information can't be gleaned from the global setting or the connection. It
seems very misleading to me to have a setIsolationLevel API (or generic
"IsolationLevel" hint) that doesn't actually change the connection's isolation
level.
If we can determine that this API is actually useful for more than DB2, and if
we can name it appropriately for what it actually does, then I like Patrick's
proposal of a FetchPlan API. The fact that all FetchPlan properties can be
expressed as hints should make everyone happy. But if this is just a DB2
thing, then we should rename the hint to have a DB2-specific name and be done
with it IMO.
> 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.
