Re: [jbosscache-dev] ReversibleCommands and locking schemes

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