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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

William Burns-3
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

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Ryan Emerson-2
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.  

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" <[hidden email]>
To: "infinispan -Dev List" <[hidden email]>
Cc: [hidden email], [hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Sanne Grinovero-3
On 1 June 2016 at 15:24, Ryan Emerson <[hidden email]> 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" <[hidden email]>
> To: "infinispan -Dev List" <[hidden email]>
> Cc: [hidden email], [hidden email]
> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Galder Zamarreño
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 <[hidden email]> wrote:
>
> On 1 June 2016 at 15:24, Ryan Emerson <[hidden email]> 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" <[hidden email]>
>> To: "infinispan -Dev List" <[hidden email]>
>> Cc: [hidden email], [hidden email]
>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Tristan Tarrant-2
+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 <[hidden email]> wrote:
>>
>> On 1 June 2016 at 15:24, Ryan Emerson <[hidden email]> 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" <[hidden email]>
>>> To: "infinispan -Dev List" <[hidden email]>
>>> Cc: [hidden email], [hidden email]
>>> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev