[jbosscache-dev] ReversibleCommands and locking schemes

[Jason T. Greene]

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.

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