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

[Sanne Grinovero]

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.

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
implement the smartest TimeService today but the
chosen API should be flexible enough to encourage such experiments.

Sanne

>
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev