4:23 a.m.
On Tue, May 14, 2013 at 10:52 AM, Sanne Grinovero <sanne(a)infinispan.org>wrote:
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. [...]
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.
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