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

[Dan Berindei]

On Tue, May 14, 2013 at 10:52 AM, Sanne Grinovero <sanne at infinispan.org>wrote:

> On 14 May 2013 08:33, Dan Berindei <dan.berindei at gmail.com> wrote:
> >
> >
> >
> > 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?
>
> Different precision requirements for eviction / expiry & co.
>
>
Playing a bit of devil's advocate here... Why would you want different
precision requirements for expiration in different caches?
Is there any other cache that supports this?



> I would expect each TimeService to be differently configured, but all
> of them could share the same "clockwork";
> I'd rather avoid discussing implementation details of such services at
> this stage, but to make a practical example let's assume
> our main clockwork uses a Timer thread to periodically update a
> volatile long; in such case the update frequency needs
> to accommodate for the requirements of each different Cache, and
> having different services makes configuration easier.
> However if you have some Cache instance which requires nanosecond
> precision, making a Timer thread an unsuitable
> implementation choice, you might still want to use the Timer thread
> for the other caches.
> It seems quite clear that a clever implementation would need different
> strategies depending on the Cache, and on the
>
requirements of the different invocation context: we don't need to
>

So you're saying having a TimeService per cache wouldn't be enough, we
might need different TimeServices for each command?



> implement the smartest TimeService today but the
> chosen API should be flexible enough to encourage such experiments.
>

The most important experiment would be to implement a TimeService with
caching and see if it really is better than what we have now. That's
certainly doable with a global TimeService.

Once we determine that the performance is indeed better, we can investigate
what would stop regular users from using it and improve those particular
scenarios. But I don't think we should start with an all-encompassing API
only to give up on it when we realize the performance benefits are minimal
and the code complexity is much higher.

https://blogs.oracle.com/ksrini/entry/we_take_java_performance_very

[...] In order to confirm the performance improvement, a constant date
value was assigned to the date, field and it was noted that a 3%
improvement may be achievable. [...]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130514/be446fc1/attachment-0001.html