[infinispan-dev] Compatiibility 2.0 dump
rvansa at redhat.com
Wed Jun 22 11:44:21 EDT 2016
I've spotted things like 'decorating cache' in the wiki page. I though
that the core architecture in Infinispan, modifying the behavior
according to configurations, is the interceptor stack. While we have
some doubts about its performance, and there are limitations - e.g. the
Flags don't allow to add custom parameters and we certainly don't want
to add Flag.JSON and Flag.XML - I would consider decorating a Cache<K,
V> vs. adding interceptors.
I am thinking of adding the transcoder information to invocation context
and only pass different ICF to the CacheImpl. Though, this requires new
factory, new interceptor and a handful of specialized context classes
(or a wrapper to the existing ones). Whoo, just decorating Cache sounds
much simpler (and probably more performant). Or should we have forks in
interceptor stack? (as an alternative to different wrappers).
The idea of interceptors is that these are common for all operations, if
we want to do things differently for different endpoints (incl.
embedded), decorating probably is the answer.
My 2c (or rather just random thoughts and whining)
On 06/21/2016 09:49 AM, Tristan Tarrant wrote:
> Hi all,
> I've created a wiki  for the "compatibility 2.0" ideas we talked
> about recently at the query meeting.
> This is mostly a dump of the minutes, so the form is not complete, but
> initial comments are welcome.
>  https://github.com/infinispan/infinispan/wiki/Compatibility-2.0
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team
More information about the infinispan-dev