theory of distributed transactions / timeouts

>>>>> "A Z" == Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:

PS: where can I find more on the distributed txn plans for PostgreSQL? Thanks.

A Z> BTW: for distributed txns you need a lock timeout feature
A Z> anyway, because detecting remote deadlocks between two or
A Z> more different servers would be very complicated. And I do
A Z> think PostgreSQL will need remote db access a la long.

A typical distributed transaction management system would consist of

- a transaction manager for that particular transaction
- an associated log manager
- an optional associated lock manager (depending on transaction type:
pessimistic, optimistic, etc)
- one or more resource managers (usually storage)

and thus the lock manager would have a single point of reference for
the existence of a transaction or not. The "distributed" part in that
scenario would be that one {log|lock|resource} manager could be client
to several transaction managers simultaneously. The problem of
deadlock detection is that of cyclic dependency-detection among
several transaction managers. Pessimistic Transaction Managers do use
locks and understand their semantics, thus they can communicate with
their peers that are accessing the shared pool of locks.

I would agree that the simplest solution for deadlock detection is a
timeout, but it certainly is not the only one.

Most desirable would be a measure to choose which transaction to
abort, which simultaneously avoids starvation (no more cycles, ever
for txn X), upper limits (txns beyond X objects / locks / cycles /
... cannot happen), etc.. A timeout mechanism is not going to
approach this measure, but an analysis of the dependency matrix with
the associated information on resource usage of each transaction might
get close.

so long,

Oliver