[infinispan-dev] Compatiibility 2.0 dump

Radim Vansa 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 [1] 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.
> Tristan
> [1] https://github.com/infinispan/infinispan/wiki/Compatibility-2.0

Radim Vansa <rvansa at redhat.com>
JBoss Performance Team

More information about the infinispan-dev mailing list