Re: Row locking and serializability

This was sloppy phrasing on my part. By "under control of the user" I meant that a user process event, namely the transaction's end, caused the lock's release.

The user's process doesn't control the lock, but the user process can delay the end of the transaction indefinitely.

Not so with page locks. The right to insert a new record into a page is transferred between various processes that are all Rdb, including Rdb processing in the context of the user's process.

These processes can all signal each other, and respond to asynchronous traps, in a way that lets them share the page in a disciplined way, without depending on the completion of a user's code.

Michael Ortega-Binderberger wrote in message ...

>Row locks are still not under user control (at least should not).
>As to when locks can safely be released, this depends on the
>characteristics of the schedule you come up with. You can get away
>with releasing locks earlier if you want to sacrifice some
>properties such as ACA. In general I believe this is not a good
>idea, although for performance reasons this could be done and would
>work best in a mostly read environment I believe.
>
>How do you say that inclreases overhead and also concurrency?
>This isn't clear to me.
>
Received on Sat Jun 12 1999 - 06:39:05 CDT