[infinispan-dev] Prepending internal cache names with org.infinispan instead of triple underscore
Galder Zamarreño
galder at redhat.com
Thu Dec 7 10:35:12 EST 2017
Tristan Tarrant <ttarrant at redhat.com> writes:
Thanks everyone, I've created a JIRA to track this:
https://issues.jboss.org/browse/ISPN-8595
> To add to Adrian's history lesson:
>
> ClusterRegistry (a single, replicated, non-persistent, scoped cache) was
> replaced with the InternalCacheRegistry which provides a common way for
> subsystems to register internal caches with the "traits" they want but
> configured to take into account some global settings. This means setting
> up proper security roles, persistent paths, etc.
>
> We do however have a proliferation of caches and in my ISPN-7776 PR I've
> reintroduced a scoped config/state cache which can be shared by
> interested parties.
>
> I do like the org.infinispan prefix for internal caches (and I've
> amended my PR to use that). I'm not that concerned about the additional
> payload, since most of the internal caches we have at the moment change
> infrequently (schema, script, topology, etc), but we should probably
> come up with a proper way to identify caches with a common short ID.
>
> Tristan
>
> On 11/6/17 10:46 AM, Adrian Nistor wrote:
>> 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 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
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
More information about the infinispan-dev
mailing list