Re: Online activity

This is a classic use of a "saga" in a long-running transaction.  I
this case, the transaction is a multistep one with the following
steps:

1) Display records available (no locks needed)
2) User selects some for edit (acquire a "reservation" or intent-to-edit lock)
3) User makes edits (intent locks held)
4) Users saves (write-locks acquired, edits saved)
5) Write locks and Intent locks released.
6) Saga ends.

Now, what makes this interesting is handling the intent-locks at step
2 and timeouts/abandons before step 5.  When you encounter that, you
need to add two other operations to the mix.

First, at step 2.5 you insert a "timed undo" operation into a work
queue. When the time of this undo expires, the "intent-to-edit" lock
is automatically released.  You can do this by doing a release
timed-out before acquire at step 2, or you can have a continuously
(scheduled) daemon process that does this.

Second, at step 5.5, you released (or just delete) the "timed-undo"
queue entry. this is safe and desirable because we now know that the
intent-lock has been deleted and thus doesn't need to be undone.

This is exactly how "ticket reservations" work. You are offered a
specific seat(s) ticket for 5 minutes, and if you don't complete the
sale before then, the tickets are released (intent locks undone).

Any further information can be found the excellent book by Bernstein &
Newcomer "Principles of Transactional Processing" specifically the
chapter on long-running transactions. http://bit.ly/HVeIr

-- 
Marc C. Brooks
http://musingmarc.blogspot.com

NOT sent from an iPhone

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives