Re: [infinispan-dev] Special cache types and their configuration (or lack of)
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(a)redhat.com>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev