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

[Galder Zamarreño]

On May 14, 2013, at 9: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.
> 
> 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.

^ In the other thread where we discussed the TimerService, I advocated precisely for the opposite when Pedro suggested it having it per cache. To me, it makes more sense to have it as a global component.

For your use case, couldn't you group your caches according to the the timer service requirements you have and put them under a single cache manager? And then have multiple cache managers according to your timer service requirements? It might be a bit far fetched… but it's certainly doable, and these cache managers could share resources such as JGroups.

I'm not convinced the use case you suggest is that common, hence why suggest a more involved set up, in exchange of saving one less component per cache :)

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


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org