Re: Avoiding any locks in SQL Servers - read and understand....its magic.

Please see below:

"Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message news:bv58ga$hn9$1_at_titan.btinternet.com...
> > > I think the point you are really making isn't about
> > > serializability, it's about commercial databases failing
> > > to implement some features of generic constraints.
> >

[VC] No, actually my point was precisely about serializability.
>

[JL] I disagree - if you re-read your comments from the last
> few lines you have said:
> Oracle does not implement database constraints
>
> We have to fake database constraints.
>
> Because our fake database constaints do not work, we can construct
> a demonstration of serializable transactions not working.
>
> Ergo, serialization is the significant issue

I think you are nit-picking here. As I mentioned several times before, the purpose of my simple demonstration was merely to show that a transaction schedule which was built using just SQL and nothing else can be non-serializable under Oracle's SIL. Let's forget the word 'constraint' for a second and look upon the test as meaning "update the linked account in such a manner as to avoid the sum of the accounts being zero'.

Besides, the write skew anomaly can also be observed when the conditon is moved to a checked view or a trigger where it (the condition) presumably becomes a 'legitimate' constraint.

>
> My line is simply that the most significant failing is that database
> constraints are not implemented (possibly in any commercial database),
> and all you have done is show that if you don't fake database constraints
> properly then you can get serialization to fail.That makes the
serialization
> issue
> secondary to the database constraint issue

Agree about this one.

Rgds.

VC Received on Tue Jan 27 2004 - 06:13:03 CST