[jbosscache-dev] ReversibleCommands and locking schemes

[Manik Surtani]

I agree re: separating the PL logic from the commands since it is  
specific to the locking scheme.

Re: OL, so far there is no OL specific logic in the commands - it all  
exists in the OL interceptors.  Agreed that it would be cleaner to  
have a separate set of commands to hold this logic, but given that we  
don't plan to support OL in the long term, I'd rather not spend the  
time and effort on this.

The only reason it makes sense for PL is that it makes the commands  
leaner and lighter for MVCC and removes irrelevant code.


On 27 Jun 2008, at 15:21, Mircea Markus wrote:

> I also vote for separate logic.
> What about creating a set of commands to hold appropriate logic for  
> optimistic licking as well - (this would contain logic moved from  
> some of the Optimistic interceptors).
> I think the code would be more readable this way, the commands would  
> be unit testable, and we would be able to optimize it  it better.
>
> Brian Stansberry wrote:
>> I'd say separate it out.  You might have to live with PL for a long  
>> time, and refactoring it later when 3.x is stable/people depend on  
>> it is more problematic.  Seems like now (or before the first  
>> 3.0.0.CR) is a better time to do this kind of stuff.
>>
>> 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?
>>>
>>> Thoughts?
>>> -- 
>>> Manik Surtani
>>> Lead, JBoss Cache
>>> manik at jboss.org
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>

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