[infinispan-dev] ClusteredGetCommand vs. SingleRpcCommand
Radim Vansa
rvansa at redhat.com
Thu May 19 03:20:28 EDT 2016
I wasn't suggesting to remove CGC nor any others - haven't had any
issues with that. Though, as I add another type of cache and compare
that to distributed non-tx cache (looking for reusable code), I try to
evaluate if any piece of code is really a proper behaviour, workaround
or just technological debt. I haven't really checked the marshalling
cost of CGC vs. SRC.
Following the pattern, I've created ClusteredGetAllCommand, too, but
when Galder gets back to Functional API, he should properly implement
the ReadOnly*Commands [1] and he'll need another command for that - or
just push those functional commands through SingleRpcCommand.
So I take this as there's no trick in CGC.
R.
[1] https://issues.jboss.org/browse/ISPN-6586
On 05/18/2016 04:33 PM, Dan Berindei wrote:
> I wasn't present in the JBoss Cache days either, but I'm guessing it's
> to allow "special" processing of the command and/or results outside of
> the interceptor chain. It also saves a bit on the marshalling cost, as
> the serialization of SingleRpcCommand isn't terribly efficient.
>
> In general, I wouldn't want to force all commands to be
> VisitableCommands -- especially custom commands that our interceptors
> probably don't know how to deal with. And TransactionBoundaryCommands
> go through the chain, but they look up the transaction and create an
> invocation context based on it, and I'm not sure that logic would fit
> in SingleRpcCommand.
>
> But I remember how long it took me to get used to the back-and-forth
> between GetKeyValueCommand and ClusteredGetCommand, so I'm all for
> removing ClusteredGetCommand.
>
> Cheers
> Dan
>
>
> On Wed, May 18, 2016 at 3:12 PM, Radim Vansa <rvansa at redhat.com> wrote:
>> Just wondering, why do we have ClusteredGetCommand (and similar ones)
>> and don't wrap GetKeyValueCommand into SingleRpcCommand as with the
>> others? Git history starts in 2009, and I think this goes to real history :)
>>
>> Radim
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team
More information about the infinispan-dev
mailing list