database operations successfully commit. The algorithm
now supports partial failures and still provides transactional guarantees without resorting to 2PC.
There is a simpler technique for assuring idempotent
updates if the only concern is ordering. Let’s change our
sample schema just a bit to illustrate the challenge and
the solution (see figure 8). Suppose you also want to track
the last date of sale and purchase for the user. You can
rely on a similar scheme of updating the date with a message, but there is one problem.
Suppose two purchases occur within a short time
window, and our message system doesn’t ensure ordered
operations. You now have a situation where, depending
Alternate Schema
user
id
name
amt_sold
amt_bought
last_sale
last_purchase
transaction
xid
seller_id
buyer_id
amount
FIG 8
upon which order the messages are processed in, you will
have an incorrect value for last_purchase. Fortunately,
this kind of update can be handled with a minor modification to the SQL, as illustrated in figure 9.
By simply not allowing the last_purchase time to go
backward in time, you have made the update operations
order independent. You can also use this approach to
protect any update from out-of-order updates. As an alternative to using time, you can also try a monotonically
increasing transaction ID.
ORDERING OF MESSAGE QUEUES
A short side note on ordered message delivery is relevant.
Message systems offer the ability to ensure that messages
are delivered in the order they are received. This can be
expensive to support and is often unnecessary, and, in
fact, at times gives a false sense of security.
The examples provided here illustrate how message
ordering can be relaxed and still provide a consistent
view of the database, eventually. The overhead required
to relax the ordering is nominal and in most cases is
significantly less than enforcing ordering in the message
system.
Further, a Web application is semantically an event-driven system regardless of the style of interaction. The
client requests arrive to the system in arbitrary order.
Processing time required per request varies. Request
scheduling throughout the components of the systems is
nondeterministic, resulting in nondeterministic queuing
of messages. Requiring the order to be preserved gives a
false sense of security. The simple reality is that nondeterministic inputs will lead to nondeterministic outputs.
SOFT STATE/EVENTUALLY CONSISTENT
Up to this point, the focus has been on trading consistency for availability. The other side of the coin is
understanding the influence that soft state and eventual
consistency has on application design.
As software engineers we tend to look at our systems
For each message in queue:
Peek message
Begin transaction
Update user set last_purchase=message.trans_date where id=message.buyer_id and last_purchase< message.trans_date;
End transaction
If transaction successful
Remove message from queue
End for
FIG 9
