Database Reference
In-Depth Information
We have lived happily without transactions, thus accepting occasional failures.
In the classic paper
Your Coffee Shop Doesn't Use Two-Phase Commit
at
http://
www.eaipatterns.com/docs/IEEE_Software_Design_2PC.pdf
, Gregor Hohpe
described the operation of asynchronous processing, which accounts for failures
with occasional losses (spilled drinks) and is different from the transaction of the
you-at-the-bank-teller relationship. This shows that we can use systems that are
not strictly deterministic as long as they give satisfactory results, more or less.
Another example would be if you are buying a topic on Amazon and discover that
at the end of the checkout, somebody has already snatched the last copy. Pechal'ka,
as the Russians would say, "A little sorrow."
All right, so having determined the parameters under which we can accept an
approximation rather than a genuine transaction, how do we implement it?
The answer is you can do it yourself. Here are the possible approaches:
• Model your transaction around a row:
We know that updates to a row in a column family are atomic. Therefore,
you can model your data in such a way that the transaction affects only one
row and you only need to update a single row in a single CF at once. Thus,
you turn around and model your data around transactions, rather than the
other way around. Admittedly, this is tricky, but it can certainly be done in
some situations.
• Model multiple rows around one locking row:
If you are only dealing with multiple row inserts (and not updates), you can
have one of the rows act as a commit by essentially validating the presence
of the other rows. For example, say you were performing an operation where
you wanted to create an account row and five user rows at once (this is an
unlikely example, but bear with me). You can insert five rows into the users'
CF and then add one row into the accounts CF, which acts as the commit.
If something went wrong before the account could be created, users that
have been created so far would be orphaned and become unusable, as your
business logic can ensure that they can't exist without an account. You could
also have an offline cleanup process that sweeps away orphans.
