[infinispan-dev] [Discussion] TimeService implementation

Pedro Ruivo pedro at infinispan.org
Fri May 3 11:54:21 EDT 2013



On 05/03/2013 04:49 PM, Manik Surtani wrote:
>
> On 2 May 2013, at 19:01, Pedro Ruivo <pedro at infinispan.org> wrote:
>
>>
>> preciseTime() {return (cached = System.nanoTime());}
>> impreciseTime() {return cached;}
>
> How would you invalidate the cached time?

My idea is to have a schedule thread updating the cached time. the 
preciseTime() is just an optimization to keep the cached value more 
up-to-date since we are calculating the nanoTime() (and assuming that 
nanoTime() is more expensive than write in the volatile variable).

>
>> Also, I think a method like boolean isExpired(long timestamp) is useful
>>>> to add to the interface.
>>>>
>>>>>
>>>>>>
>>>>>> * Scope:
>>>>>>
>>>>>> Should the TimeService be in a cache or global scope? My vote is per
>>>>>> cache…
>>>>>
>>>>> ^ My feeling is that it should be global. Why per cache?
>>>>
>>>> When recovery is enabled, the recovery manager creates a second cache.
>>>> Someone may want to replace the Clock/TimeService for the "normal" cache
>>>> and left the default implementation in the "recovery" cache.
>>>
>>> ^ Why would an end-user want to replace the Clock/TimeService?
>>>
>>> Remember what I said in my previous email: I can see someone changing the service implementation for testing reasons, and in that case, a global clock/timer service that's swapable via system property would work just fine IMO.
>>
>> I don't know. I'm being pessimist and assuming that someone in the world
>> as a dark use case and needs to replace the service.
>>
>> Looking at the code, it is easiest for me to use a global service :)
>
> +1 to a global service.
>
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>


More information about the infinispan-dev mailing list