T - Type of the cached data.public interface TimeStampedGenerator<T extends TimeStamped>
time stamped caches.
As long as a generator is referenced by one cache only, it is
guaranteed to be called in a thread-safe way, even if the cache is used in a multi-threaded
environment. The cache takes care of scheduling the calls to all the methods defined in
this interface so only one thread uses them at any time. There is no need for the
implementing classes to handle synchronization or locks by themselves.
The generator is provided by the user of the cache and should
be consistent with the way he will use the cached data.
If entries must have regular time gaps (for example one entry every 3600 seconds), then the generator must ensure by itself all generated entries are exactly located on the expected regular grid, even if they are generated in random order. The reason for that is that the cache may ask for entries in different ranges and merge these ranges afterwards. A typical example would be a cache first calling the generator for 6 points around 2012-02-19T17:48:00 and when these points are exhausted calling the generator again for 6 new points around 2012-02-19T23:20:00. If all points must be exactly 3600 seconds apart, the generator should generate the first 6 points at 2012-02-19T15:00:00, 2012-02-19T16:00:00, 2012-02-19T17:00:00, 2012-02-19T18:00:00, 2012-02-19T19:00:00 and 2012-02-19T20:00:00, and the next 6 points at 2012-02-19T21:00:00, 2012-02-19T22:00:00, 2012-02-19T23:00:00, 2012-02-20T00:00:00, 2012-02-20T01:00:00 and 2012-02-20T02:00:00. If the separation between the points is irrelevant, the first points could be generated at 17:48:00 instead of 17:00:00 or 18:00:00. The cache will merge arrays returned from different calls in the same global time slot.
| Modifier and Type | Method and Description |
|---|---|
List<T> |
generate(AbsoluteDate existingDate,
AbsoluteDate date)
Generate a chronologically sorted list of entries to be cached.
|
List<T> generate(AbsoluteDate existingDate, AbsoluteDate date)
If existingDate is earlier than date, the range covered by
generated entries must cover at least from existingDate (excluded)
to date (included). If existingDate is later than date,
the range covered by generated entries must cover at least from date
(included) to existingDate (excluded).
The generated entries may cover a range larger than the minimum specified above
if the generator prefers to generate large chunks of data at once. It may
generate again entries already generated by an earlier call (typically at existingDate), these extra entries will be silently ignored by the cache.
Non-coverage of the minimum range may lead to a loss of data, as the gap will
not be filled by the GenericTimeStampedCache in subsequent calls.
The generated entries must be chronologically sorted.
existingDate - date of the closest already existing entry (may be null)date - date that must be covered by the range of the generated arrayCopyright © 2002-2020 CS Group. All rights reserved.