Re: Transactions: good or bad?

"Nigel Day" <nigelday_at_fast24.co.uk> wrote in message news:b985990ikl_at_enews2.newsguy.com...
> A transaction is what the DBMS lets you do as a unitary operation: its a
> group of changes to be performed as a unit, such that if anything goes wrong
> the whole set is rolled back.

> So transactions per se don't give problems
> with the 'arrow of time'

This depends on a more accurate definition of what a transaction is that you provided above. In particular you need to define whether in your definition of a transaction they are *atomic in time*.

If, in the logical model, your transactions are instantaneous alterations to the value of the database, then indeed transactions don't give problems with the arrow of time. Unfortunately that is not what is always meant by a transaction. Often a transaction consists of a number of logical actions that occur over a period of time, but are 'wrapped up' with the ability to 'roll back' these changes **even though they have already occurred** if 'anything goes wrong'

In the 'arrow of time' assumption, it is not possible to go back in time and alter (i.e. roll back) something that has already happened.

The above notwithstanding, your example of a problem with locks is valid. Also you are right to separate the two concepts.

I claim:

   Locks are bad only when they break the information principle.

   Transactions in the logical model* are inherently bad.

• maybe I should say 'in the Logical Theory of Data' instead ;-)

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Tue May 06 2003 - 18:02:05 CEST