Informix has the following
SET TRANSACTION
<http://publib.boulder.ibm.com/infocenter/idshelp/v10/topic/com.ibm.sqls.doc/sqls02.htm#ToC_987>
Use
the SET TRANSACTION statement to define the isolation level and to specify
whether the access mode of a transaction is read-only or read-write.
Syntax
[image: Read syntax diagram][image: Skip visual syntax diagram]
<http://publib.boulder.ibm.com/infocenter/idshelp/v10/topic/com.ibm.sqls.doc/sqls815.htm?resultof=%22%74%72%61%6e%73%61%63%74%69%6f%6e%22%20%22%74%72%61%6e%73%61%63%74%22%20%22%69%73%6f%6c%61%74%69%6f%6e%22%20%22%69%73%6f%6c%22%20#skipsyn-276>>>-SET
TRANSACTION---------------------------------------------->
.-,------------------------------------------------.
V (1) |
----+--------+-READ WRITE-+------------------------+-+--------><
| '-READ ONLY--' |
| (1) |
'--------ISOLATION LEVEL--+-READ COMMITTED---+-'
+-REPEATABLE READ--+
+-SERIALIZABLE-----+
'-READ UNCOMMITTED-'
SQLServer has the following
[image: Syntax]Syntax<http://msdn2.microsoft.com/en-us/library/ms173763.aspx#>
SET TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED
| READ COMMITTED
| REPEATABLE READ
| SNAPSHOT
| SERIALIZABLE
}
[ ; ]
On 4/5/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:
[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487086]
Patrick Linskey commented on OPENJPA-182:
-----------------------------------------
> > I know that Oracle allows you to add a FOR UPDATE clause
> > to a query, and this affects the results of that query. In Sun
> > appserver CMP we use this to set exclusive locks on rows
> > where we want pessimistic locking behavior just for certain tables.
>
> Again, this is exactly what our existing lock levels and APIs do.
The current patches in this issue encompass two separate bits of
functionality:
1. an update-override setting. (In the context of my patch, I'm not
convinced that this is necessary, since I suspect that the code that calls
toSelect() might set the forUpdate boolean based on the values in the
JDBCFetchConfiguration anyways.)
2. an isolation-override setting.
Currently, this patch implements all of this only in the DB2Dictionary. As
of right now, the first feature is something that is useful for all sorts of
databases, via syntax like Oracle's SELECT ... FOR UPDATE. However, we only
know how to implement the second feature for DB2, and not for any other
database. In Oracle, "ALTER SESSION" can be used to change the isolation
level of a given session, but I'm not sure of the semantics of this
operation. I believe that Abe's question is: Do other databases (Sybase?
Derby?) also have semantics for changing the isolation level of a particular
query?
> 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.
