[infinispan-dev] Special cache types and their configuration (or lack of)

[Radim Vansa]

There's one glitch that needs to be stressed: some limitations of 
simplified cache are not discoverable on creation time. While 
persistence, tx and others are, adding custom interceptors and running 
map-reduce or distributed-executors can't be guessed when the cache is 
created.
I could (theoretically) implement MR and DistExec, but never the custom 
interceptors: the idea of simple cache is that there are *no 
interceptors*. And regrettably, this is not as rare case as I have 
initially assumed, as for example JCaches grab any cache, insert their 
interceptor and provide the wrapper.

One way to go would be to not return the simple cache directly, but wrap 
it in a delegating cache that would switch the implementation on the fly 
as soon as someone tries to play with interceptors. However, this is not 
without cost - the delegate would have to read a volatile field and 
execute megamorphic call upon every cache operation. Applications could 
get around that by doing instanceof and calling unwrap method during 
initialization, but it's not really elegant solution.

I wanted the choice transparent to the user from the beginning, but it's 
not a way to go without penalties.

For those who will suggest 'just a flag on local cache': Following the 
'less configuration, not more' I believe that the amount of 
runtime-prohibited configurations should be kept at minimum. With such 
flag, we would expand the state space of configuration 2 times, while 
95% of the configurations would be illegal. That's why I have rather 
used new cache mode than adding a flag.

Radim

On 07/27/2015 04:41 PM, Tristan Tarrant wrote:
> Hi all,
>
> I wanted to bring attention to some discussion that has happened in the
> context of Radim's work on simplified code for specific cache types [1].
>
> In particular, Radim proposes adding explicit configuration options
> (i.e. a new simple-cache cache type) to the programmatic/declarative API
> to ensure that a user is aware of the limitations of the resulting cache
> type (no interceptors, no persistence, no tx, etc).
>
> My opinion is that we should aim for "less" configuration and not
> "more", and that optimizations such as these should get enabled
> implicitly when the parameters allow it: if the configuration code
> detects it can use a "simple" cache.
>
> Also, this choice should happen at cache construction time, and not
> dynamically at cache usage time.
>
> WDYT ?
>
> Tristan
>
> [1] https://github.com/infinispan/infinispan/pull/3577


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