[infinispan-dev] ReplicateCommand

Manik Surtani manik at jboss.org
Tue Mar 31 07:16:54 EDT 2009


On 31 Mar 2009, at 12:02, Mircea Markus wrote:

> 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.
> There still are two built objects being built, ReplicateCommand and  
> the aggregated ReplicableCommand[], that's my concern.
> Re:getParameters, I see that there is an array built in that  
> command, which contains the param list. what about creating an array  
> pool, and pass them to the command, i.e. the signature would be:  
> getParameters(Object[] params)?

Well, this is unnecessary if we go with different impls as suggested  
below.

>
>>
>>> 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.
> Yep, see your point re: composite.
>>
>> So, the interface it implements is more appropriately named  
>> (CacheRPCCommand).  Perhaps there should be 2 separate  
>> implementations, SingleRPCCommand, MultipleRPCCommand?
>>
>>
>> --
>> Manik Surtani
>> Lead, JBoss Cache
>> http://www.jbosscache.org
>> manik at jboss.org <mailto:manik at jboss.org>
>>
>>
>>
>>
>

--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik at jboss.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20090331/543fdbc7/attachment-0001.html 


More information about the infinispan-dev mailing list