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

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&gt; > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 08/05/2015 03:37 PM, Dan Berindei wrote: > 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. What UI do you mean? IDE with XSD, or does Infinispan have any tool with Mr. Clippy?

Not having a button/configuration element is IMO the _proper_ way to tell the user 'You can't do that', rather than showing pop-up/throwing exception with 'Don't press this button, please!'. I admit that exception with link to docs is more _BFU-proof_, though. If users really cared about the schema, there wouldn't be so many threads where they try to copy-paste embedded configuration into server. The parser error message should be more ironic, like 'Something's wrong. I won't tell you what, but your XSD schema validator will!'

> > 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. +1 I was about to write the dynamic switcher, but having consistent performance is strong argument against that. Radim > > Cheers > Dan > > > > On Wed, Aug 5, 2015 at 11:48 AM, Galder Zamarreno <galder(a)redhat.com&gt; 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(a)redhat.com&gt; >>> JBoss Performance Team >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

It seems that I am outnumbered by the 'new local-cache attribute' camp (though not convinced!). If there is not any other input on this topic, I'll migrate that to local attribute, since I want to squeeze simple cache to 8.0.0.Final (That attribute will need to be explicitly set, I will not implement any hot-switch) Radim On 08/05/2015 10:24 PM, Dan Berindei wrote: > On Wed, Aug 5, 2015 at 5:31 PM, Radim Vansa <rvansa(a)redhat.com&gt; wrote: >> On 08/05/2015 03:37 PM, Dan Berindei wrote: >>> 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. >> What UI do you mean? IDE with XSD, or does Infinispan have any tool with >> Mr. Clippy? > I meant the server (and WildFly) management console. No Clippy there, > at least not yet :) > >> Not having a button/configuration element is IMO the _proper_ way to >> tell the user 'You can't do that', rather than showing pop-up/throwing >> exception with 'Don't press this button, please!'. I admit that >> exception with link to docs is more _BFU-proof_, though. If users really >> cared about the schema, there wouldn't be so many threads where they try >> to copy-paste embedded configuration into server. The parser error >> message should be more ironic, like 'Something's wrong. I won't tell you >> what, but your XSD schema validator will!' >> > I admit having only the options that really work in the XSD and > relying on the XSD to point out mistakes seems cleaner. My concern is > discoverability: the user may be looking for an option that's only > available on a local-cache, and there's nothing telling them to > replace simple-cache with local-cache. > >>> 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. >> +1 I was about to write the dynamic switcher, but having consistent >> performance is strong argument against that. >> >> Radim >> >>> Cheers >>> Dan >>> >>> >>> >>> On Wed, Aug 5, 2015 at 11:48 AM, Galder Zamarreno <galder(a)redhat.com&gt; 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(a)redhat.com&gt; >>>>> JBoss Performance Team >>>>> >>>>> _______________________________________________ >>>>> infinispan-dev mailing list >>>>> infinispan-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Radim Vansa <rvansa(a)redhat.com&gt; >> JBoss Performance Team >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

The simple cache is just a thin wrapper over DataContainer, and uses listeners, CacheNotifier and all that stuff from infinispan-core. The low-dependency part is BoundedConcurrentHashMap.

Radim On 08/07/2015 11:32 AM, Sanne Grinovero wrote: > > +1 > If it doesn't get too complex, I would love to see that packaged in a > low-dependency module. That's of course secondary, but we'd be using > it in many more projects. > > Thanks, > Sanne > > On 7 Aug 2015 10:05, "Radim Vansa" <rvansa(a)redhat.com > <mailto:rvansa@redhat.com>> wrote: > > It seems that I am outnumbered by the 'new local-cache attribute' camp > (though not convinced!). If there is not any other input on this > topic, > I'll migrate that to local attribute, since I want to squeeze simple > cache to 8.0.0.Final > (That attribute will need to be explicitly set, I will not > implement any > hot-switch) > > Radim > > On 08/05/2015 10:24 PM, Dan Berindei wrote: > > On Wed, Aug 5, 2015 at 5:31 PM, Radim Vansa <rvansa(a)redhat.com > <mailto:rvansa@redhat.com>> wrote: > >> On 08/05/2015 03:37 PM, Dan Berindei wrote: > >>> 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. > >> What UI do you mean? IDE with XSD, or does Infinispan have any > tool with > >> Mr. Clippy? > > I meant the server (and WildFly) management console. No Clippy > there, > > at least not yet :) > > > >> Not having a button/configuration element is IMO the _proper_ > way to > >> tell the user 'You can't do that', rather than showing > pop-up/throwing > >> exception with 'Don't press this button, please!'. I admit that > >> exception with link to docs is more _BFU-proof_, though. If > users really > >> cared about the schema, there wouldn't be so many threads where > they try > >> to copy-paste embedded configuration into server. The parser error > >> message should be more ironic, like 'Something's wrong. I won't > tell you > >> what, but your XSD schema validator will!' > >> > > I admit having only the options that really work in the XSD and > > relying on the XSD to point out mistakes seems cleaner. My > concern is > > discoverability: the user may be looking for an option that's only > > available on a local-cache, and there's nothing telling them to > > replace simple-cache with local-cache. > > > >>> 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. > >> +1 I was about to write the dynamic switcher, but having consistent > >> performance is strong argument against that. > >> > >> Radim > >> > >>> Cheers > >>> Dan > >>> > >>> > >>> > >>> On Wed, Aug 5, 2015 at 11:48 AM, Galder Zamarreno > <galder(a)redhat.com <mailto:galder@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(a)redhat.com <mailto:rvansa@redhat.com>> > >>>>> JBoss Performance Team > >>>>> > >>>>> _______________________________________________ > >>>>> infinispan-dev mailing list > >>>>> infinispan-dev(a)lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >>>>> > >>>> _______________________________________________ > >>>> infinispan-dev mailing list > >>>> infinispan-dev(a)lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >>> _______________________________________________ > >>> infinispan-dev mailing list > >>> infinispan-dev(a)lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >> > >> -- > >> Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> > >> JBoss Performance Team > >> > >> _______________________________________________ > >> infinispan-dev mailing list > >> infinispan-dev(a)lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev(a)lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev