James K. Lowden wrote:

Since very few (if any) live production Ingres systems use MVCC I
approach this discussion assuming that consistency is created by doing
pessimistic locking.

In an ideal DBMS all the updates of a transaction would be
simultaneous, so the concept of doing updates out-of-order or in-order
is an unwelcome intrusion from the physical implementation.
Unfortunately SQL only allows us to peck away at the database
table-by=table, row-by-row so the DBMS has to try various clever
gimmicks to hide the problems. Sometimes the gimmicks don't work out
and we get a deadlock.

In the Ingres world the problem isn't invariably or even usually the
application program. For example, there is nothing the application
programmer can do to prevent the deadlock that can be induced when the
server decides to escalate to a table level lock in mid-transaction.

If the programmer is confident that the transaction can safely be
re-tried (i.e. there is no possibility that the database has
already changed in a way that makes the intended update(s) invalid) I
can't see why an automatic re-try shouldn't be coded. It's a pain the
a*se to have to write code that way, but it's a pain the a*se to use
SQL at all.

Anyway, all this is moot IMO since we have no idea where our
transactions begin. *That* is the first problem to solve--then we can
argue about looping over them or not later.

And use MVCC (until something better comes along).

--
Roy

UK Ingres User Association Conference 2012 will be on Tuesday June 19 2012.
*NOTE THE CHANGED DATE* See www.uk-iua.org.uk