- All Implemented Interfaces:
public class Expiry extends Object implements ExpiryTimeValuesUtility methods and constants to use inside expire policy or resilience policy.
- Jens Wilke
- See Also:
Fields inherited from interface org.cache2k.expiry.ExpiryTimeValues
ETERNAL, NEUTRAL, NOW, REFRESH
Constructors Constructor Description
All Methods Static Methods Concrete Methods Modifier and Type Method Description
earliestTime(long loadTime, long candidate1, long candidate2)Helper to calculate the next expiry out of two expiry times that may be up next.
mixTimeSpanAndPointInTime(long loadTime, long refreshAfter, long pointInTime)Combine a refresh time span and an expiry at a specified point in time.
toSharpTime(long millis)Convert the time value to a time representing a sharp expiry.
public static long toSharpTime(long millis)Convert the time value to a time representing a sharp expiry. This essentially negates the time value and is provided for a more speaking coding style.
millis- expiry time since the milliseconds since epoch or
ExpiryTimeValues.ETERNALif no expiry is requested.
IllegalArgumentException- if the time value is negative
public static long earliestTime(long loadTime, long candidate1, long candidate2)Helper to calculate the next expiry out of two expiry times that may be up next. Return the time value that is closest or equal to the load time. Time values in the past are ignored. If all times are in the past, returns
loadTime- the current time in millis since epoch
candidate1- candidate time for next expiry
candidate2- candidate time for next expiry
- either first or second candidate or
public static long mixTimeSpanAndPointInTime(long loadTime, long refreshAfter, long pointInTime)Combine a refresh time span and an expiry at a specified point in time.
If the expiry time is far ahead of time the refresh time span takes precedence. If the point in time is near, 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 in 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 and 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 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.