[infinispan-dev] Prepending internal cache names with org.infinispan instead of triple underscore

Radim Vansa rvansa at redhat.com
Fri Nov 3 04:42:36 EDT 2017


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 at infinispan.org 
> <mailto:sanne at infinispan.org>> wrote:
>
>     On 2 November 2017 at 22:20, Adrian Nistor <anistor at redhat.com
>     <mailto:anistor at 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 at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     >
>     >
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto: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


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



More information about the infinispan-dev mailing list