+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 <sa...@infinispan.org> wrote: >> >> On 1 June 2016 at 15:24, Ryan Emerson <remer...@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" <mudokon...@gmail.com> >>> To: "infinispan -Dev List" <infinispan-dev@lists.jboss.org> >>> Cc: d...@infinispan.org, remer...@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@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
