Re: Serializability of Transactions and Automatic (Number) Generators

Yes, this reminds me in some way of a discussion I had with Alistair Cockburn on his assertion that reflective environmnet breaks Liskov Substitution Principle for objects.

I.e that a function

f(BaseType o) {
  return o.getClass().getName();
}

will return different results for an object of the base class and the derived class.

I replied that this doesn't break LSP because LSP does not guarantee a fixed result for such a function, but actually guarantees that all the logical derivation from contracts (pre-conditions => post-conditions) would hold when at runtime objects of derived classes are substituted.

Since in the above, in presence of reflection and subtyping one cannot derive that result=="BaseType" no contract is broken.

Similarly (although I don't know of anybody who did it) in database history, we can define serializability to mean *not* that the same image of the database is obtained (which clearly is impossible with Oracle sequences and similar generators), but rather that all logical derivations about what conditions hold true in the end, are kept invariant under all serializabe histories.

just my 2c,
Costin

Jonathan Leffler wrote:
> In general, a set of transactions is considered serializable if it is
> equivalent to some serial execution of the same transactions (for
> example, see Bernstein, Hadzilacos and Goodman "Concurrency Control and
> Recovery in Database Systems", section 1.3 "Serializability").
>
> Modern DBMS usually have one or more ways of automatically generating
> values during a transaction - Oracle (and most other DBMS) have SEQUENCE
> types; Informix has the SERIAL type; other DBMS have other similar
> constructs.
>
> In general, the values automatically generated during a transaction are
> not generated again, even if the original transaction is rolled back.
> Further, there is nothing to stop a pair of transactions from
> alternately generating new values - V(n) to TxA, V(n+1) to TxB, V(n+2)
> to TxA, V(n+3) to TxB, and so on.
>
> Does this mean that such transactions are inherently non-serializable,
> or does it mean that the specific values generated by a transaction are
> not material for the discussion of equivalence of executions?
>
> If TxA were executed before TxB, it would obtain the values V(n) and
> V(n+1) -- rather than V(n) and V(n+2) as shown above -- but for all
> practical purposes, the results are equivalent: two new unique values
> unused by any other transaction were generated and the specific values
> are immaterial.
>
> Any thoughts?
>
Received on Thu Nov 25 2004 - 06:52:52 CET