Hi, >>>>> "Oyvind" == Oyvind Bakksjo <[EMAIL PROTECTED]> 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. Dag
