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

[Mircea Markus]

On Oct 28, 2013, at 10:55 AM, Galder Zamarreño <galder at 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 <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
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)