|Constructor and Description|
|Modifier and Type||Method and Description|
Helper to calculate the next expiry out of two expiry times that may be up next.
Combine a refresh time span and an expiry at a specified point in time.
Convert the time value to a time representing an a sharp expiry.
public static long toSharpTime(long millis)
public static long earliestTime(long loadTime, long candidate1, long candidate2)
loadTime- the current time in millis since epoch
candidate1- candidate time for next expiry
candidate2- candidate time for next expiry
public static long mixTimeSpanAndPointInTime(long loadTime, long refreshAfter, long pointInTime)
If the expiry time is far ahead of time the refresh time span takes
precedence. If the point in time is close by this time takes precedence.
If the refresh time is too close to the requested point an earlier refresh
time is used to keep maximum distance to the requested point time, which is
abs(pointInTime) - refreshAfter
Rationale: Usually the expiry is allowed to lag behind. This is okay when a normal expiry interval is used. If sharp expiry is requested an old value may not be visible at or after the expiry time. Refresh ahead implies lagging expiry, since the refresh is triggered when the value would usually expire. The two concepts can be combined in the expiry policy, e.g. using an interval for triggering refresh ahead and requesting a sharp expiry only when needed. If effective expiry time for the lagging variant and the for the sharp variant are in close proximity, conflicts need to be resolved.
loadTime- time when the load was started
refreshAfter- time span in milliseconds when the next refresh should happen
pointInTime- time in milliseconds since epoch for the next expiry. Can be negative if sharp expiry is requested, or
ExpiryTimeValues.ETERNALif no point in time expiry is needed.
cache2k API documentation. Copyright © 2000–2017 headissue GmbH, Munich.