[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