Tristan Tarrant <ttarrant(a)redhat.com> writes:
Thanks everyone, I've created a JIRA to track this:
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(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
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>