Re: Transactions: good or bad?

"Bob Badour" <bbadour_at_golden.net> wrote in message news:66dwa.385$lY6.74435714_at_mantis.golden.net...
> Logically and conceptually, a single atomic assignment statement against a
> single resource cannot cause deadlock.

Absolutely

> For your model to have legitimate
> worth, I think it needs to deliver us from deadlock.

Agreed and if I can do that then it makes it a much better sell ;-)

The model itself will not deadlock, but dumbly polling clients using it can. One benefit of current systems is that deadlock detection is something the DBMS can perform. For this reason, I want to include a 'wait upon condition' function into the model. If clients are coded to 'acquire locks' over multiple db assignments, and poll for changes in lock values when a lock cannot be acquired, then I cannot detect a such client deadlock (although nor can any DBMS). But if instead of polling they ask the DBMS to wait for them upon a condition (i.e. a particular query returning TRUE) then the database can reject any waits that would result in a deadlock (or deadwait as I could call it)

> Under a transactionless dbvar assignment
> model with optimistic concurrency, deadlock and starvation avoidance become
> core requirements for physical and logical independence

Agreed.

The model needs not only to understand the concept of time, but now also of say 'Thread' (and maybe User, Connection and Client...)

<further thoughts taken offline>

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Wed May 14 2003 - 11:45:59 CEST