into a separate back-end component, you preserve the
availability of your customer-facing component. The
lower availability of the message processor may be acceptable for business requirements.
Suppose, however, that 2PC is simply never acceptable
in your system. How can this problem be solved? First,
you need to understand the concept of idempotence. An
operation is considered idempotent if it can be applied
one time or multiple times with the same result. Idempotent operations are useful in that they permit partial
failures, as applying them repeatedly does not change the
final state of the system.
The selected example is problematic when looking
for idempotence. Update operations are rarely idempotent. The example increments balance columns in place.
Applying this operation more than once obviously will
result in an incorrect balance. Even update operations
that simply set a value, however, are not idempotent
with regard to order of operations. If the system cannot
guarantee that updates will be applied in the order they
are received, the final state of the system will be incorrect.
More on this later.
In the case of balance
updates, you need a way to
track which updates have
been applied successfully
and which are still outstanding. One technique is
to use a table that records
the transaction identifiers
that have been applied.
The table shown in
figure 6 tracks the transaction ID, which balance has
been updated, and the user
ID where the balance was
applied. Now our sample
pseudocode is as shown in
figure 7 .
This example depends
upon being able to peek a
message in the queue and
remove it once success-
f ully processed. This can
be done with two indepen-
d ent transactions if neces-
FIG 7 s ary: one on the message
q ueue and one on the user
d atabase. Queue operations
a re not committed unless
U pdateTa ble
updates_applied
trans_id
balance
user_id
FIG 6
dequeue each message and apply the information to the
user table. The example appears to solve all of the issues,
but there is a problem. The message persistence is on the
transaction host to avoid a 2PC during queuing. If the
message is dequeued inside a transaction involving the
user host, we still have a 2PC situation.
One solution to the 2PC in the message-processing
component is to do nothing. By decoupling the update
B e gintransaction
Insert into transaction(id, seller_id, buyer_id, amount);
Queue message “update user(“seller”, seller_id, amount)”;
Queue message “update user(“buyer”, buyer_id, amount)”;
E nd transaction
F or each message in queue
Peek message
Begin transaction
Select count(*) as processed where trans_id=message.trans_id
and balance=message.balance and user_id=message.user_id
If processed == 0
If message.balance == “seller”
Update user set amt_sold=amt_sold + message.amount
where id=message.id;
Else
Update user set amt_bought=amt_bought + message.amount
where id=message.id;
End if
Insert into updates_applied
( message.trans_id, message.balance, message.user_id);
End if
End transaction
If transaction successful
Remove message from queue
End if
