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(a)jboss.org _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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

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.