db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik" <Dag.Wan...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-231) "FOR UPDATE" required for updatable result set to work
Date Fri, 28 Oct 2005 14:02:31 GMT

>>>>> "Oyvind" == Oyvind Bakksjo <Oyvind.Bakksjo@Sun.COM> wrote:

> > In contrast, Oracle's "FOR UPDATE" places locks on the entire result
> > set for the duration of the transaction (see below). The usefulness as
> > a way to control locking would be more useful if the Derby locking was
> > closer to what Oracle does, at the expense of concurrency.
> > 
> > Dag
> Just a little pick at the wording... What's "useful" behaviour depends 
> on the application and its needs. If you don't need update locks on the 
> entire result set, the "usefulness" of such a behaviour is negative, 
> since it only reduces concurrency and, as such, overall performance.

Obviously it is dependent on the application.  My point is that if the
application wants to lock all rows of a result set, with actually
updating them (necessarily), the current Derby semantics (releasing
the update lock once a next() is executed), isn't very helpful. I was
under the impression that was the kind of usage Dan was aiming at when
he argued that FOR UPDATE should be permissible is even if the result
set has concurrency read-only.


View raw message