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

On 14 May 2013 08:33, Dan Berindei <dan.berindei@gmail.com> wrote:
>
>
>
> On Mon, May 13, 2013 at 8:44 PM, Sanne Grinovero <sanne@infinispan.org>
> wrote:
>>
>> On 13 May 2013 18:32, Manik Surtani <msurtani@redhat.com> wrote:
>> >
>> > On 13 May 2013, at 16:25, Mircea Markus <mmarkus@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. [...]