21 April, 1999 Vincenzo Innocente LHC++ Meeting1 Time-Ordered Persistent Collections Vincenzo Innocente CMS Collaboration see also contribution to RD45 workshop of 4/98

21 April, 1999 Vincenzo Innocente LHC++ Meeting2 Problem l Given an object, whose state depends upon time, I want to know its state for any given time in the past (and predict the future?) n Its state is determined from direct or deduced measurements (or equivalent procedure) of unspecified nature, precision and frequency l Well known solution: the object store a history of its measured states in a time-series and compute the best value for a given time using a suitable interpolation or extrapolation algorithm.

21 April, 1999 Vincenzo Innocente LHC++ Meeting3 Assumptions (Requirements??) l Writing (insertion in the collection): n once (never delete, never modify in place) n in object natural time order n by a single producer l Object Time Validity n until a new object is inserted n at each time one, and only one object, is valid (per version)

21 April, 1999 Vincenzo Innocente LHC++ Meeting4 Assumptions (Requirements??) l Version Validity n Data themselves are WORM, the collection may not s objects are obsoleted only by “versioning” n a version “tags” all objects in a certain time period s for a given “tag” and a given time a valid object should exists n an object can belong to more than one version n current version makes sense n all versions should be available n reproducing the state of the collection at a given past time should be possible

21 April, 1999 Vincenzo Innocente LHC++ Meeting5 Assumptions (Requirements??) l Obsolescence: n rare process: few new versions will be created (0-10) n some objects can NOT be obsoleted (sort of raw-data) n In most of the cases all objects belonging to a certain time period will be obsoleted at the same time n Often the validity time of the new version will be the same of the previous version n In some cases the new version will have a different time granularity (usually finer)

21 April, 1999 Vincenzo Innocente LHC++ Meeting6 Assumptions (Requirements??) l Read: n Very very often, by multiple clients n besides online applications, current real time is not special at all n often in natural sequence, not necessarily contiguous n random access is NOT a secondary scenario n interpolation (and extrapolation?) should be supported, not necessarily implemented

21 April, 1999 Vincenzo Innocente LHC++ Meeting7 Assumptions (Misuses) l Versioning should be used only for making object obsolete n NOT to keep two different concurrent “version” of the same “logical entity” (for instance: online and offline calibrations): use distinct collections n The same applies for “user” and “test” versions (even transient ones) n NOT to differentiate among different parts of the detector: use different collections or different components in the same “super-object”

21 April, 1999 Vincenzo Innocente LHC++ Meeting8 Assumption summary (Primary Scenarios) l Data (measurements) are WORM and not related to time collections by themselves l Main insertion mode is “push_back” l Random update is not frequent and it is the result of a computing intensive activity l A new “release tag” affects long “time periods” l Random reading will be frequent l Interpolation/extrapolation should be left to the application software

21 April, 1999 Vincenzo Innocente LHC++ Meeting9 Persistent Architecture Version (Insertion time) Time

21 April, 1999 Vincenzo Innocente LHC++ Meeting10 Persistent Architecture Version (Insertion time) Time

21 April, 1999 Vincenzo Innocente LHC++ Meeting11 Time Series (column-wise) Insertion time Persistent List of stacks (time- slices) This mechanism guarantees that the selected object is valid for the whole time slice

21 April, 1999 Vincenzo Innocente LHC++ Meeting12

21 April, 1999 Vincenzo Innocente LHC++ Meeting13 Transient Components