[jbosscache-dev] ReversibleCommands and locking schemes

[Manik Surtani]

On 27 Jun 2008, at 20:39, Jason T. Greene wrote:

> Manik Surtani wrote:
>> 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.  :)
>
> Ok so you could have the per-command strategy also decide whether or  
> not to do that:
>
> putStrategy.recordUndo(old,...);
> putStrategy.rollback();
>
> This could of course be also done using a traditional inheritance  
> model, but I suspsect you are going to need locking-model specfic  
> callbacks either way.
>
> IMO i think the goal should be to implement MVCC with good code, and  
> not care so much about pessimistic and optimistic, since long term  
> we know we are going to drop them.

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