[infinispan-dev] TimeService (ISPN-3069): CacheLoader API break

[Dan Berindei]

On Mon, May 13, 2013 at 8:44 PM, Sanne Grinovero <sanne at infinispan.org>wrote:

> On 13 May 2013 18:32, Manik Surtani <msurtani at redhat.com> wrote:
> >
> > On 13 May 2013, at 16:25, Mircea Markus <mmarkus at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130514/b662e349/attachment.html