Re: Serializability of Transactions and Automatic (Number) Generators

I guess I forgot to add that since the only valid deduction about values generated by a sequence generators is that those values are distinct across different invocations, than the preservation of this property is trivial under even less than serializable isolation levels.

Costin Cozianu wrote:
> 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?
>>