On Mon, May 13, 2013 at 8:44 PM, Sanne Grinovero <sa...@infinispan.org>wrote:
> On 13 May 2013 18:32, Manik Surtani <msurt...@redhat.com> wrote: > > > > On 13 May 2013, at 16:25, Mircea Markus <mmar...@redhat.com> wrote: > > > >> > >> On 13 May 2013, at 15:05, Manik Surtani wrote: > >> > >>>> 100% agree, most users will have to interact with AdvancedCache at > some point - if only because of lock() and withFlags(). > >>> > >>> I've seen quite a bit of end-user code that doesn't touch > AdvancedCache. > >> I'm on Dan's side here, I think it's pretty popular through the users > and should be considered as public API. A note on the same lines, we also > recommend all our users to use Flag.IGNORE_RETURN_VALUE, which again goes > trough AdvancedCache. > > > > So you're saying getTimeService() should be in EmbeddedCacheManager? > That's Dan's argument... I really don't think this should be accessible by > end-user applications. > > +1 to keep it hidden, but SPI kind of API wouldn't be too bad. > > If we want to keep it hidden, then I think it would be best to leave the getTimeService() method only in ComponentRegistry/GlobalComponentRegistry and remove it from the AdvancedCache interface. We might want to remove it from the configuration, too. > More importantly, I'd design it in such a way that different Caches > could be using a different one. Doesn't have to be supported in the > current code implementation, I just mean API-wise this should not be > on a "global" component but on a Cache-specific one. > > Any particular usage in mind for having a different time service in each cache? We definitely need a global component, because JGroupsTransport uses it, so we'd have to support both. Cheers Dan
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev