I also vote for separate logic. What about creating a set of commands to hold appropriate logic for optimistic licking as well - (this would contain logic moved from some of the Optimistic interceptors). I think the code would be more readable this way, the commands would be unit testable, and we would be able to optimize it it better. Brian Stansberry wrote: > 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(a)jboss.org >> >> >> >> >> >> >> _______________________________________________ >> jbosscache-dev mailing list >> jbosscache-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosscache-dev >