Re: [jbosscache-dev] ReversibleCommands and locking schemes

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?