Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server

On Mon, 1 Dec 1997 21:31:39 +0000, David Williams <djw_at_smooth1.demon.co.uk> wrote:
> Imagine 1 page with 2 rows one it.
>
> 1. Page level locking
>
> User A updates row 1
> At the same time user B updates row 2. User B has to wait for
> User B to commit.
>
> 2. With row level locking
> User A updates row 1
> User B updates row 2 (with no waiting).
>
> How can 1 be faster than 2 if user B has to wait?

Although I am not an SQL guru, coming from a COBOL background, the above statement is realy *nonsense*.

Any good and decent programmer, would not lock a record (sorry, row...) while interacting with the user. This is at least common to record based systems and I assume the same applies here. When the user hits update, the the code with the locks executes in one batch, and fast. So when another wants the row to update at the same moment, it would *not* notice a wait, as the command(s) should execute immediately.

The problem would arise in programs where the row is locked, and some user input is expected and then an action would be taken to free the locked row. This is sloppy programming, because the user may just go for coffee leaving the row(s) locked for an unspecified time.

To check if the data is ok when the user hits the update/delete for example, the program may check if the row has been modified since it was retrieved and if notm do the action, otherwise notify the user that the data has been changed meanwhile and procceed according to user input.

So there is no point on row vs page locking, the only thing that matters is that the transactions needs to be done fast. And if is faster with page locking, then the whole system is faster, although some users may want to update a row that is locked due to PPL.

Regards
Ragards

Savas Pavlidis

pavlidis_at_cosmos.ibm.net

Please remove cosmos from the email address. Needed to avaoid spamming. Thank you. Received on Fri Dec 05 1997 - 00:00:00 CET