On May 14, 2013, at 9:52 AM, Sanne Grinovero <sanne(a)infinispan.org> wrote:
On 14 May 2013 08:33, Dan Berindei <dan.berindei(a)gmail.com>
wrote:
>
>
>
> On Mon, May 13, 2013 at 8:44 PM, Sanne Grinovero <sanne(a)infinispan.org>
> wrote:
>>
>> On 13 May 2013 18:32, Manik Surtani <msurtani(a)redhat.com> wrote:
>>>
>>> On 13 May 2013, at 16:25, Mircea Markus <mmarkus(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org