[infinispan-dev] Singleton Cache Stores with Shared Cache Stores

Tristan Tarrant ttarrant at redhat.com
Tue Jun 7 05:05:15 EDT 2016


+1 to remove this.

Tristan

On 06/06/2016 15:09, Galder Zamarreño wrote:
> The singleton store goes back to the JBC days and I don't remember a single use of it in the wild, so happy to get rid of it.
>
> Cheers,
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 1 Jun 2016, at 16:35, Sanne Grinovero <sanne at infinispan.org> wrote:
>>
>> On 1 June 2016 at 15:24, Ryan Emerson <remerson at redhat.com> wrote:
>>> After further discussions on IRC, we have concluded the following:
>>>
>>> In shared mode only the primary owner of a key writes to the shared store,
>>> therefore there is no obvious use-case for having a singleton mode which
>>> delegates all writes to a single node.
>> As far as I remember, the *intent* was to allow dealing with stores
>> which can't handle concurrent writes, i.e. needing a global lock.
>>
>> We had different CacheStore implementations back then, I guess some of
>> them might have had exotic limitations.
>>
>> I don't know which practical use case people had in mind though: it's
>> likely we already dropped any implementation which could need this
>> long ago, so no objections about getting rid of it.
>>
>> Thanks,
>> Sanne
>>
>>> With this in mind, I propose that the singleton option and associated
>>> writers be deprecated [1]. If anybody has any objections, please speak up.
>>>
>>> [1] https://issues.jboss.org/browse/ISPN-6748
>>>
>>> Cheers
>>> Ryan
>>>
>>> ----- Original Message -----
>>> From: "William Burns" <mudokonman at gmail.com>
>>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>>> Cc: dan at infinispan.org, remerson at redhat.com
>>> Sent: Wednesday, 1 June, 2016 2:54:13 PM
>>> Subject: Singleton Cache Stores with Shared Cache Stores
>>>
>>> Recently there was a start of a discussion regarding singleton cache stores
>>> and how they behave.  Interestingly according to our documentation [1] and
>>> verification code [2] a singleton store cannot be used with a shared cache
>>> store.  This makes no sense to me as this means you would have a single
>>> point of failure for your data.  And also as Dan pointed out [3] there is
>>> no Singleton cache loader to make sure all the loads are from the
>>> coordinator either, which means you could have a read that returns null
>>> despite it being in the store/loader.
>>>
>>> And even looking at [4] it talks about singleton being used so not every
>>> node writes to the underlying store, which implies it being shared.
>>>
>>> I think we have enough proof to update this so a singleton store requires a
>>> shared store, but I wanted to make sure we weren't missing something here.
>>>
>>> Thanks,
>>>
>>> - Will
>>>
>>> [1]
>>> http://infinispan.org/docs/9.0.x/user_guide/user_guide.html#_configuration_2
>>> [2]
>>> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/configuration/cache/PersistenceConfigurationBuilder.java#L108
>>> [3] https://github.com/infinispan/infinispan/pull/4382#discussion_r65360312
>>> [4]
>>> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/persistence/support/SingletonCacheWriter.java#L40
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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