>>>>> "DJD(" == Daniel John Debrunner (JIRA) <[email protected]> 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
