db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oystein.Grov...@Sun.COM (Øystein Grøvlen)
Subject Re: [jira] Commented: (DERBY-231) "FOR UPDATE" required for updatable result set to work
Date Tue, 23 Aug 2005 14:09:25 GMT
>>>>> "DJD(" == Daniel John Debrunner (JIRA) <derby-dev@db.apache.org>
writes:

    DJD(>     [ http://issues.apache.org/jira/browse/DERBY-231?page=comments#action_12319651
] 
    DJD(> Daniel John Debrunner commented on DERBY-231:
    DJD(> ---------------------------------------------

    DJD(> The FOR UPDATE support is probably more from a 'de-facto'
    DJD(> standard than the SQL spec. Most, if not all, other
    DJD(> databases support a FOR UPDATE on a SELECT statement. It is
    DJD(> heavily used by application servers (e.g. EJB
    DJD(> implementations). Removing it would affect a lot of existing
    DJD(> applications.

One problem is that some application servers (e.g., Sun's) assume a
de-facto standard implementation of "SELECT FOR ... UPDATE" which is
incompatible with how Derby implements it.  That is, the Sun
App. Server uses FOR UPDATE for its "lock-when-loaded" consistency
level.  For databases that does not support this implementation (DB2,
Sybase, and Derby), this consistency level is not available.  I asked
why the could not use REPEATABLE READ.  Their argument was that
REPEATABLE READ would enforce the same locking on all beans within a
transaction.  With FOR UPDATE they can do bean-specific locking.

I think this shows that there is often a need for database
applications to have more control over concurrency mechanisms than
what is covered by the SQL standard.

-- 
Øystein


Mime
View raw message