From: Matthew French (mfrench42 at domain yahoo.co.uk)
Date: Tue 24 Sep 2002 - 23:07:03 IST
Waider was feeling ambitous:
> Regarding the usefulness or otherwise of transactions, I think if you
> want a proper shared-storage cluster setup to actually not eat your
> data ever, you need transactions. Otherwise, you blow up a server and
> boom, inconsistent data almost guaranteed.
Eeeek. Shared transactions.
Handling transactions across more than one machine can be a thankless task.
To ensure a transaction is committed properly, you need to send a message
back to notify that the transaction has been committed. But what if this
message never reaches its destination? How can you tell if the transaction
was committed or not? So you have to confirm the transaction confirmation.
And then confirm the confirmation of the confirmation. And so on...
Never mind what happens if one commit fails while the other succeeds.
Thus most distributed systems use a two phase commit, which is basically
every system in the transaction saying "Right ready to go." and being ready
to roll back if something else in the cluster fails. Most architects seem to
try avoid these systems like the plague.
The classic example for transactions is the bank account transfer: SELECT
accounts; DECREASE account1; INCREASE account2; COMMIT. If something breaks
between the decrease and increase and you have no transaction, then one has
money disappearing into the ether. You also have a problem similar to
multi-threaded applications: what if two transfers happen on the same
account at the same time?
Which is why ACID is important (Atomic, Consistent, Isolated, Durable). It
basically means that whatever happens, the data should still be in an
It is also one of those features that, if implemented properly, you should
never have to know about.
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:19:02 GMT