Different internal caches have different needs regarding consistency,
tx, persistence, etc...
The first incarnation of ClusterRegistry was using a single cache and
was implemented exactly as you suggested, but had major shortcomings
satisfying the needs of several unrelated users, so we decided to split.
On 11/03/2017 10:42 AM, Radim Vansa wrote:
Because you would have to duplicate entire Map on each update,
unless
you used not-100%-so-far functional commands. We've used the ScopedKey
that would make this Cache<ScopedKey<PURPOSE, Object>, Object>. This
approach was abandoned with ISPN-5932 [1], Adrian and Tristan can
elaborate why.
Radim
[1]
https://issues.jboss.org/browse/ISPN-5932
On 11/03/2017 09:05 AM, Sebastian Laskawiec wrote:
> I'm pretty sure it's a silly question, but I need to ask it :)
>
> Why can't we store all our internal information in a single,
> replicated cache (of a type <PURPOSE, Map<Object, Object>). PURPOSE
> could be an enum or a string identifying whether it's scripting cache,
> transaction cache or anything else. The value (Map<Object, Object>)
> would store whatever you need.
>
> On Fri, Nov 3, 2017 at 2:24 AM Sanne Grinovero <sanne(a)infinispan.org
> <mailto:sanne@infinispan.org>> wrote:
>
> On 2 November 2017 at 22:20, Adrian Nistor <anistor(a)redhat.com
> <mailto:anistor@redhat.com>> wrote:
> > I like this proposal.
>
> +1
>
> > On 11/02/2017 03:18 PM, Galder ZamarreƱo wrote:
> >> Hi all,
> >>
> >> I'm currently going through the JCache 1.1 proposed changes,
> and one that made me think is [1]. In particular:
> >>
> >>> Caches do not use forward slashes (/) or colons (:) as part of
> their names. Additionally it is
> >>> recommended that cache names starting with java. or
> javax.should not be used.
> >> I'm wondering whether in the future we should move away from
> the triple underscore trick we use for internal cache names, and
> instead just prepend them with `org.infinispan`, which is our
> group id. I think it'd be cleaner.
> >>
> >> Thoughts?
> >>
> >> [1]
https://github.com/jsr107/jsr107spec/issues/350
> >> --
> >> Galder ZamarreƱo
> >> Infinispan, Red Hat
> >>
> >>
> >> _______________________________________________
> >> 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
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev