Transactions

["Tom Locke" <tsl2@xxxxxxxxx>]

Hello Again!

I'm interested to see that you've been talking about transactions, as myself
and Peter had a (very short) conversation about this. In the IT industry,
transactions make the world go round so if we good do something clever here,
it would get us far.

Most of the discussion seemed to look at transactions as a kind of
synchronisation (to a man with a hammer, everything looks like a nail).

I think transactions a more about persistent state - they even make sense
within a single threaded program.

The ACID acronym captures the idea well:

 A  Atomic

 In terms of the effect on system state.

 C  Consistent

 System state can not become inconsistent

 I Isolated

 A transaction is isolated from the effect of other
 transactions, which of course means that one transaction
 may not be able to start until another finishes.

 D Durable

 This is a very important! Once the transaction completes, the
 change of state can survive a crash (i.e. it's on disk)

Due to 'I' it is of course a synchronisation too. People rarely seem to
worry about deadlock arising from a cycle of blocked transactions. The
general belief is that the database makes it all work, and there's nothing
to worry about.

We are about to enter an age of millions of globaly distributed concurrent
transactions, maybe these issues are about to bite.

So the question is -- what have we got to offer -- I'm not sure yet. Anyone?

Tom.