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(a)infinispan.org> wrote:
>
> On 1 June 2016 at 15:24, Ryan Emerson <remerson(a)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(a)gmail.com>
>> To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
>> Cc: dan(a)infinispan.org, remerson(a)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/o...
>> [3]
https://github.com/infinispan/infinispan/pull/4382#discussion_r65360312
>> [4]
>>
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
>> _______________________________________________
>> 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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev