Re: Transactions: good or bad?

From: Bob Badour <bbadour_at_golden.net>
Date: Tue, 13 May 2003 16:19:28 -0400
Message-ID: <66dwa.385$lY6.74435714_at_mantis.golden.net>


"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:b9qev4$381u$1_at_gazette.almaden.ibm.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:P21wa.367$xF5.71850115_at_mantis.golden.net...
> > "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> > news:b9nu5p$2f7s$1_at_gazette.almaden.ibm.com...
> > > I allow no rollbacks in my model (short of system failures)
> >
> > Is deadlock a system failure?
> >
>
> No. In my scheme locks are just plain old relational data. Clients would
have
> to poll to wait for a change in a lock value so making deadlocks a client
> issue!!

Yuck. Serialized database variable assignments have no logical reason to cause deadlock because a database variable is a single resource and assignment is an atomic operation. Under a transactionless dbvar assignment model with optimistic concurrency, deadlock and starvation avoidance become core requirements for physical and logical independence.

I suggest that different products could compete on the basis of the different avoidance strategies they deliver, but that avoidance is required.

> However, I am toying with the idea of some generalised 'wait until
condition'
> ability, that would allow clients to wait on other's locks as well as any
> other database condition.

The only logical condition required is: Wait until my predecessor releases the single resource before commencing. Strategies could involve determining who precedes whom and at what time.

> As part of such an ability, the DBMS might be able
> to provide a 'deadwait' detection system between seperate clients. I'm
waiting
> on something only you can change, you're waiting on something that only I
can
> change. Or rather it might be better to have a constraint on 'wait until
> conditions' that prevents the acceptence of any deadlocked waits requests
in
> the first place.

Logically and conceptually, a single atomic assignment statement against a single resource cannot cause deadlock. For your model to have legitimate worth, I think it needs to deliver us from deadlock. I see that as one of the most important benefits from discarding transactions in favour of dbvar assignments. Received on Tue May 13 2003 - 22:19:28 CEST

Original text of this message