<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Tue, May 14, 2013 at 10:52 AM, Sanne Grinovero <span dir="ltr"><<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On 14 May 2013 08:33, Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, May 13, 2013 at 8:44 PM, Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>><br>
> wrote:<br>
>><br>
>> On 13 May 2013 18:32, Manik Surtani <<a href="mailto:msurtani@redhat.com">msurtani@redhat.com</a>> wrote:<br>
>> ><br>
>> > On 13 May 2013, at 16:25, Mircea Markus <<a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a>> wrote:<br>
>> ><br>
>> >><br>
>> >> On 13 May 2013, at 15:05, Manik Surtani wrote:<br>
>> >><br>
>> >>>> 100% agree, most users will have to interact with AdvancedCache at<br>
>> >>>> some point - if only because of lock() and withFlags().<br>
>> >>><br>
>> >>> I've seen quite a bit of end-user code that doesn't touch<br>
>> >>> AdvancedCache.<br>
>> >> I'm on Dan's side here, I think it's pretty popular through the users<br>
>> >> and should be considered as public API. A note on the same lines, we also<br>
>> >> recommend all our users to use Flag.IGNORE_RETURN_VALUE, which again goes<br>
>> >> trough AdvancedCache.<br>
>> ><br>
>> > So you're saying getTimeService() should be in EmbeddedCacheManager?<br>
>> > That's Dan's argument... I really don't think this should be accessible by<br>
>> > end-user applications.<br>
>><br>
>> +1 to keep it hidden, but SPI kind of API wouldn't be too bad.<br>
>><br>
><br>
> If we want to keep it hidden, then I think it would be best to leave the<br>
> getTimeService() method only in ComponentRegistry/GlobalComponentRegistry<br>
> and remove it from the AdvancedCache interface.<br>
><br>
> We might want to remove it from the configuration, too.<br>
><br>
><br>
>><br>
>> More importantly, I'd design it in such a way that different Caches<br>
>> could be using a different one. Doesn't have to be supported in the<br>
>> current code implementation, I just mean API-wise this should not be<br>
>> on a "global" component but on a Cache-specific one.<br>
>><br>
><br>
> Any particular usage in mind for having a different time service in each<br>
> cache?<br>
<br>
</div></div>Different precision requirements for eviction / expiry & co.<br>
<br></blockquote><br></div><div class="gmail_quote">Playing a bit of devil's advocate here... Why would you want different precision requirements for expiration in different caches?<br></div><div class="gmail_quote">
Is there any other cache that supports this?<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I would expect each TimeService to be differently configured, but all<br>
of them could share the same "clockwork";<br>
I'd rather avoid discussing implementation details of such services at<br>
this stage, but to make a practical example let's assume<br>
our main clockwork uses a Timer thread to periodically update a<br>
volatile long; in such case the update frequency needs<br>
to accommodate for the requirements of each different Cache, and<br>
having different services makes configuration easier.<br>
However if you have some Cache instance which requires nanosecond<br>
precision, making a Timer thread an unsuitable<br>
implementation choice, you might still want to use the Timer thread<br>
for the other caches.<br>
It seems quite clear that a clever implementation would need different<br>
strategies depending on the Cache, and on the<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
requirements of the different invocation context: we don't need to<br></blockquote><div><br></div><div>So you're saying having a TimeService per cache wouldn't be enough, we might need different TimeServices for each command?<br>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
implement the smartest TimeService today but the<br>
chosen API should be flexible enough to encourage such experiments.<br>
<span class=""></span></blockquote><div><br></div><div>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.<br>
<br></div><div>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.<br>
<br><a href="https://blogs.oracle.com/ksrini/entry/we_take_java_performance_very">https://blogs.oracle.com/ksrini/entry/we_take_java_performance_very</a><br><br><span style="color:rgb(85,85,85);font-family:Arial,Verdana,sans-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:18px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);display:inline!important;float:none">[...] 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.<span class=""> </span></span>[...]<br>
</div></div></div></div>