[jbosscache-dev] ReversibleCommands and locking schemes

[Manik Surtani]

On 27 Jun 2008, at 18:57, Jason T. Greene wrote:

> 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".

The thing is, it is more than just strategy or behaviour wrt handling  
a rollback.  Currently even in perform the commands collect info with  
which to perform a rollback, such as old state being overwritten.   
Which is a waste with 2/3rds of our locking strategies.  :)

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