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

[Dan Berindei]

Radim's implementation already throws exceptions when the application
tries to use unsupported features like throwing exceptions. The
question is how to choose the simple cache: a new CacheMode/XML
element, an attribute on the local-cache element, or reusing the
existing configuration to figure out whether the user needs advanced
features.

Radim's implementation uses a new CacheMode and a new "simple-cache"
XML element. I feel this makes it too visible, since it's based on
what we can do now without an interceptor stack, and that might change
in the future.

I'm in the "new local-cache attribute" camp, because the programmatic
configuration has to validate all those impossible configurations
anyway. In the UI as well, when a user tries to create a cache with a
store, I think it's better to tell him explicitly that he can't add a
store to a simple cache, than let him wonder why there isn't any
option to add a store in Infinispan.

I don't really like the idea of switching the cache implementation
dynamically, either. From the JIT's point of view, I think a call site
in an application is likely to always use the same kind of cache, so
the call will be monomorphic most of the time. But as a user, I'd
rather have something that's constantly slow than something that's
initially fast and then suddenly gets slower without me knowing why.

Cheers
Dan



On Wed, Aug 5, 2015 at 11:48 AM, Galder Zamarreno <galder at redhat.com> wrote:
> Indeed, JCache, MR and DistExec assume you'll be given a fully fledged Cache instance that allows them to do things that go beyond the basics, so as correctly pointed out here, it's hard to make the distinction purely based on the configuration.
>
> My gut feeling is that we need a way to specifically build a simple/basic cache directly based on your use case. With existing usages out there, you can't simply get a simple/basic cache just like that since a lot of the existing use cases expect to be able to use advanced features. An easy solution, as hinted by Radim, would be to have a wrapper for a simple/basic cache, which takes a standard Cache in, but don't go as far as to allow dynamic switching. E.g. if you chose to build a simple/basic cache, then things like add interceptor would fail...etc. I think this would work well for scenarios such as 2LC where we can control how the cache to be used is constructed. However, in scenarios where we expect it to work magically with existing code, it'd not work due to the need to know about the wrapper.
>
> Cheers,
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
> ----- Original Message -----
>> 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
>>
>> _______________________________________________
>> 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