Re: incoherent view of serializable transactions

Sorry if I'm restating the obvious, however I don't understand the
confusion, as it seems the standard's definition isn't mysterious; it
simply requires that the resulting state from the concurrent execution
of transactions (and implicitly any subset) designated to occur at the
isolation level SERIALIZABLE be equivalent to SOME LITERALLY SERIAL
execution of said transactions.

Thereby although of course transactions literally executed serially
comply; they need not be executed literally serially, as long as some
mechanism is used to warrant that the state resulting from the completion
of every such transaction in some sequence be equivalent to the literally
serial execution of the transactions in the same sequence.

Thereby even if only a subset of such concurrently executed transactions
may be complete at some point in time, any potentially remaining such
transactions may be restarted for whatever reason and remain compliant
(as the resulting state from the concurrent execution of such transactions
will be equivalent to some literal serial execution of said transactions
upon the completion of each so executed transaction; correspondingly any
implementation which can not warrant the same, is simply non-compliant).

Thereby although no pre-specified completion order exists per-se, the
order of completion of transactions implicitly determine if incomplete
transactions may need to be restarted if dependant on a preceding completed
transaction's resulting mutated state (or alternatively allowed to proceed
if previously blocked on said potentially mutated state).

Thereby although a collection of such concurrently executed transactions
my have mutual interdependencies, each subsequent complete transaction in
effect break dependency deadlocks as may otherwise logically exist; and
thereby may affect optimal logical execution order of remaining such
transactions potentially concurrently; and be warranted to never deadlock.
I believe IMHO.