Re: Transactions: good or bad?

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:b9t3cm$2hm2$1_at_gazette.almaden.ibm.com...
> "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.

Without transactions and locks, how can clients cause deadlock? It could only happen within the scope of an assignment, and that is fully under the control of the dbms.

> One benefit of current systems is that deadlock detection is something the
> DBMS can perform.

Deadlock generally occurs now because of transactions; although, it can happen under the covers as well. When it occurs under the covers due to the physical access paths chosen, I believe the complexities of transactions prevent the dbms from resolving the issue short of a rollback. Without transactions, where do deadlocks come from? Why can't the dbms recover from them without error?

> For this reason, I want to include a 'wait upon condition'
> function into the model.

As I said previously, the condition is built into the transactionless model. In essense, it is "wait until the dbvar becomes available for assignment". The dbms might optimistically proceed with two concurrent assignment statements that your "arrow of time" places in some order. When deadlock occurs, the dbms must undo and redo some or all of one assignment statement, which will then occur after the assignment that proceeds unimpeded. The dbms may have to adjust the time of one of the assignments so that the time reflects the actual order of assignment.

Because deadlocks will only occur as the result of the physical access paths chosen, and not because of any user choice, it makes no sense to ask users to set locks or to use mutex semaphores or anything else.

> If clients are coded to 'acquire locks' over multiple
> db assignments

In a transactionless model, clients have no need to acquire locks over multiple dbvar assignments. They only need a sufficiently expressive language for dbvar assignments.

> > 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...)

'Thread' is an internal, physical artefact. Conceptually and logically from the perspective of users, connections and clients, assignments occur in sequence along your "arrow of time". Received on Wed May 14 2003 - 18:50:42 CEST