db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-231) "FOR UPDATE" required for updatable result set to work
Date Tue, 23 Aug 2005 17:18:17 GMT
I will leave the syntax battle to the experts, but want to note
that at the language/store interface it is important to know the
difference between a select for update and a read only select.
We use U locks in the select for update which are less deadlock
prone, then if we just got shared locks on the select and then
requested the X lock if updates are done on the result of the
select loop.

If the for update requirement is removed then some work will probably
have to be done to get the jdbc info somehow correlated into the
query compiler so that it knows that the select is for update or not.
I don't know if this done already, or if not how hard it would be.

Bernt M. Johnsen wrote:

>>>>>>>>>>>>>Rick Hillegas (JIRA) wrote (2005-08-23
>>    [ http://issues.apache.org/jira/browse/DERBY-231?page=comments#action_12319649
>>Rick Hillegas commented on DERBY-231:
>>I'm a little confused about why Derby allows a FOR UPDATE clause on
>>naked SELECT statements. I would appreciate a pointer to where the
>>SQL 2003 spec supports this syntax. This is my reading of the SQL
>>2003 spec:
>>The SELECT statement is defined in Volume 2, section 7.12 of the SQL
>>2003 spec in the <query specification> production. This production
>>does not allow a FOR UPDATE clause.
>>The FOR UPDATE clause (the <updatability clause> production) is
>>defined inside section 14.1 of the same spec, the <declare cursor>
>>production. Looking through the index, it appears that an
>><updatability clause> is only legal in the context of a cursor.
> You have to consult "Part 5: Host Language Bindings (SQL/Bindings)"
> too to actually comprehend what the standard actually says. Since the
> JDBC API kind of does what Part 5 is descibing, requiring FOR UPDATE
> actually makes sense (but it took 3 of us in Trondheim to figure it
> out.... the SQL standard has become way too large ;-( )
>>I recommend removing this non-standard syntax from naked SELECT
>>statements which are not embedded in cursors.
> I think it should not be removed (see above), but it could be made
> optional (for compatability with other db's and since its redundant in
> JDBC where one have to specify CONCUR_UPDATABLE too)

View raw message