Hi all,
I had a recent discussion with a site over the meaning of
Entity.CreationTime and Entity.Validity.
I wanted to share my thoughts and see whether others have the same view
and whether this might be worth documenting: either as part of an
updated GLUE document or as some auxiliary document (a "GLUE Processing
Model" perhaps).
The core question is this: how to know when published data is stale?
Prima facie, this is easy: simply add Entity.Validity to
Entity.CreationTime. If the resulting time is in the past then the
object is stale.
It becomes slightly tricky when considering an object that passes though
several caching agents, with each agent pulling updated information
periodically.
[For those that don't know, this is how the EGEE information system
currently works; there are three caching levels ("resource-level",
"site-level", "top-level"). Each level has the same software, "BDII",
with different configuration.]
First off, I assert that the current info-provider model (a script that
provides the current up-to-date information) cannot publish
Entity.Validity. With a pull-update model, the info-provider cannot
know when the next request will come. (To illustrate this, consider two
agents calling the info-provider with different schedules, or an
info-provider that supplies information "on demand" whenever a user
clicks on some web-page). As the info-provider cannot know when the
next request will come, it cannot set an Entity.Validity value.
However, the info-provider can publish an Entity.CreationTime. Let's
suppose it does. Let's also suppose that the first agent (the
resource-level BDII) queries every two minutes. Ideally, the BDII will
read the data and calculates what Entity.Validity is needed so that
Entity.Validity+Entity.CreationTime is two minutes in the future. It
then records this Entity.Validity along with the original
Entity.CreationTime.
If (somehow) this data is observed after the two minutes has elapsed, it
is clear that the data is stale.
Note that it is also possible (i.e., logically self-consistent) for the
BDII to reset the Entity.CreationTime to the current time. I suggest
this isn't done as knowing the original creation time could be quite useful.
The same procedure would happen for the higher levels: each one would
calculate a (potentially new) Entity.Validity so that the object will
not be valid after it anticipates fetching fresh data. This calculated
Entity.Validity would replace any that already exists in the supplied data.
Assuming you agree with this approach, there are some open questions:
1. should the agent (BDII) reset Entity.CreationTime (I'd say "no"),
2. should the agent (BDII) add an Entity.CreationTime if the source does
not provide one?
3. what should the agent (BDII) do when faced with stale data? Should
it simply log a warning or should it reject the data?
Any thoughts?
Cheers,
Paul.
