Re: [infinispan-dev] ClusteredGetCommand vs. SingleRpcCommand
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(a)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(a)redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team