[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:
In terms of the effect on system state.
System state can not become inconsistent
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.
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?