[jbosscache-dev] ReversibleCommands and locking schemes

[Manik Surtani]

A sub-interface of Command is ReversibleCommand, which exposes a  
rollback() method.  The purpose of this method is that for commands  
that change the state of the cache, the command also maintains  
information on how to undo it's change, and the undo operation is  
invoked by calling rollback() on the command.  A nice, clean way of  
encapsulating a change and it's reversal.

Now this only made sense for pessimistic locking, where changes are  
made directly on the cache.  With optimistic locking, changes are made  
in a workspace and a rollback is performed by simply throwing away the  
workspace.  MVCC is similar in this regard, where changes are made to  
a copy of the node, and a rollback is performed by throwing away this  
new node.

So, is rollback() (and the ReversibleCommand interface) tied to  
pessimistic locking only?  And if so, that is a lot of overhead each  
command stores for the sake of a single locking scheme (especially  
when those commands are used with Optimistic Locking or MVCC).  Should  
we introduce another set of commands, subclasses to the actual  
commands themselves, implementing rollback, such that they are used  
for pessimistic locking, while leaner commands without rollback can be  
used for the other locking schemes?  Or should we just "live with"  
this overhead until MVCC stabilises and we deprecate/remove  
pessimistic and optimistic locking altogether?

Thoughts?
--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org