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

[Pedro Ruivo]

Hi,

This was discussed in the last day in Farnborough. The idea is to keep 
the visitX methods for each type of operations (something like):

* visitPutCommand
* visitRemoveCommand
* visitReplaceCommand
* visitRemoveIfEqualsCommand
* visitReplaceIfEqualsCommand
* visitPutIfAbsentCommand

and finally a last method:

* visitWriteCommand

In our current stack implementation, the visitX will only invoke the 
last one (because the logic is the same for all types of commands) but 
for CustomInterceptors we decide to keep them if a user may want to 
intercept only a type of commands.

Cheers,
Pedro

On 10/28/2013 10:55 AM, Galder Zamarreño 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.
>
> 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
>