Re: [jbosscache-dev] ReversibleCommands and locking schemes

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. :)