Re: Transactions: good or bad?
Date: Tue, 13 May 2003 16:19:28 -0400
"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> > "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
> to poll to wait for a change in a lock value so making deadlocks a client
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
> 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
> on something only you can change, you're waiting on something that only I
> change. Or rather it might be better to have a constraint on 'wait until
> conditions' that prevents the acceptence of any deadlocked waits requests
> 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