[infinispan-dev] Improve WriteCommand processing code and [possibly] performance

[Galder Zamarreño]

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. 

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 <pedro at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org