On Oct 28, 2013, at 10:55 AM, Galder Zamarreño <gal...@redhat.com> wrote:
> Hi Pedro, > > I like the idea. Reducing the number of visitX commands for write commands > would be a good thing from the POV of adding new interceptors. +1. It would also enforce code reuse between operations that amend the cache. > > What would happen with existing visitPutKey…etc methods? Would this dissapear > or would they be left there still for those interceptors that want to do > something specific to each command? > > Cheers, > > On Oct 25, 2013, at 7:17 PM, Pedro Ruivo <pe...@infinispan.org> wrote: > >> Hi guys. >> >> I've open a JIRA to tack this: https://issues.jboss.org/browse/ISPN-3664 >> >> Suggestions/feedback is appreciated. This is probably be integrated in >> the next major (but no promises). >> >> I was not cleared just ping me. >> >> Have a nice weekend folks :) >> >> Regards, >> Pedro >> >> Description is the following: >> >> Major refactorization of the write command with the following goals: >> >> * Base WriteCommand: all the write command has the same workflow through >> the interceptor chain >> * Create a concrete WriteCommand for each operation (put, remove, >> replace, replaceIfEquals, removeIfEquals, putIfAbsent) >> * Extend the interceptor chain to process each one of the command and >> add a new "visitWriteCommand", that is invoked by the default visitX >> methods. >> * (minor) change the GetKeyValueCommand to ReadCommand to make name >> "compatible" with WriteCommand. >> >> Note that most of the interceptor only needs to implement the >> visitWriteCommand because all the write command has the same execution >> flow. The basic flow of the write commands are: (non-tx) lock, fetch >> value (cachestore/remote), check condition and apply change. for tx >> mode, lock (if pessimistic), fetch value (cache loader, remote, etc), >> apply change and add it to the transaction (if successful) >> >> Also, another advantage is the simplification of the EntryFactory >> because if we think a little about it, independent of the write command >> we need to wrap the entry anyway. >> >> Suggested implementation >> >> class abstract WriteCommand, >> Object key, Object newValue >> boolen match(Object currentValue) //true by default >> boolean needsRemoteGetBeforeWrite() //true by default >> object perform() //common implementation like: if >> (match(entry.getValue()) then entry.setValue(newValue); >> entry.setChanged(true); entry.setRemoved(newValue == null)} >> >> * Concrete implementations * >> >> {PutCommand|RemoveCommand} extends WriteCommand >> ovewrite needsRemoteGetBeforeWrite() {return >> !flags.contains(IGNORE_RETURN_VALUE)} >> >> ReplaceIfPresentCommand extends WriteCommand >> ovewrite match(Object currentValue) {return currentValue != null} >> >> PutIfAbsentCommand extends WriteCommand >> ovewrite match(Object currentValue) {return currentValue == null} >> >> * Special base class for operation with expected value to compare * >> >> class abstract AdvancedWriteCommand extends WriteCommand >> Object expectedValue >> match(Object currentValue) {return currentValue.equals(expectedValue)} >> >> {RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no >> different implementation needed. >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Galder Zamarreño > gal...@redhat.com > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev