[infinispan-dev] ReplicateCommand

Galder Zamarreno galder.zamarreno at redhat.com
Tue Mar 31 12:46:56 EDT 2009



Manik Surtani wrote:
> 
> On 31 Mar 2009, at 11:16, Mircea Markus wrote:
> 
>> Hi,
>>
>> Some thought on ReplicateCommand.
>> It is also used to replicate a single command, which is inefficient, 
>> as 2 objects are unnecessarily created: the ReplicateCommand itself 
>> and an array holding only one object.
>> Why not replicated the aggregated command directly?
> 
> The actual command is replicated directly.  See 
> ReplicateCommand.getParameters().  There is just an extra int in the 
> byte stream containing the number of commands contained.
> 
>> Another thing about the name: even though it is correct, it sounds 
>> very much like ReplicableCommand. I suggest renaming to 
>> CompositeCommand, or ContainerCommand.
>> wdyt?
> 
> Agreed about the name.  Don't like CompositeCommand or ContainerCommand 
> though, they both suggest a command that holds other commands.  That is 
> not this command's primary purpose.  It's primary purpose is to 
> "transport" a command across a network and execute the command on a 
> remote cache.
> 
> So, the interface it implements is more appropriately named 
> (CacheRPCCommand).  Perhaps there should be 2 separate implementations, 
> SingleRPCCommand, MultipleRPCCommand?

2 separate implementations would make sense each with a different 
perform() implementation & constructors.

Agree on the names suggested too.

> 
> 
> -- 
> Manik Surtani
> Lead, JBoss Cache
> http://www.jbosscache.org
> manik at jboss.org
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat



More information about the infinispan-dev mailing list