[jbosscache-dev] ReversibleCommands and locking schemes

[Jason T. Greene]

Manik Surtani wrote:
> 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?
> 

I would have to look at the code in more detail, but perhaps a 
per-locking style strategy makes sense? In some cases the strategy may 
be "do nothing", or it might not for commands like "move".

-- 
Jason T. Greene
JBoss, a division of Red Hat