openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ritika Maheshwari" <ritikams...@gmail.com>
Subject Re: [jira] Updated: (OPENJPA-182) db2 update lock syntax WITH <isolation> USE AND KEEP UPDATE LOCKS
Date Thu, 05 Apr 2007 16:51:27 GMT
>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.

No it is not a typo.It was intended.



On 4/4/07, Patrick Linskey (JIRA) <jira@apache.org> wrote:
>
>
>     [
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message