[jbosscache-dev] ReversibleCommands and locking schemes

[Brian Stansberry]

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

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com