Athena Developer Guide

Athena
Chapter 8 StoreGate - the event data access model Version/Issue: 2.0.0
8.7 Store Access Policy
The current release (Release 1.3.2) has some of the tools to implement a flexible access policy to
objects stored in the TDS. The TDS owns the DataObjects that have been recorded into it. A
DataObject in the store may not be deleted by the client code. Client code is allowed to modify objects
in the store but only until the DataObject is declared ``complete'' and “set constant” (locked) by its
creator.
Locking an object prevents the clients downstream of the creator to modify the reconstructed objects
by mistake. For example, a tracking algorithm that retrieves a hit collection from the store does not own
those hits and therefore may not modify them. Remember that these hits can be used later by another
tracking algorithm for which your modifications may be meaningless or even plain wrong. We do not
want the results of the second tracking algorithm to change when you run the second algorithm before
or after the first! If we want to have reproducible results from several million lines of reconstruction
code it is vital to preserve the state of every DataObject which has been reconstructed and ``published''
in the TDS to be used by others. However, well controlled modifications are desirable. The access
policy allows multiple algorithms to collaborate in reconstructing a DataObject. As an example,
consider a Calorimeter Clustering package makes cluster objects and subsequently may make
corrections, based on the Calorimeter information alone that are independent of any downstream
analysis. Since cluster finding and corrections are more or less independent, it may be desirable to have
the two decoupled: a cluster-finding sub-algorithm and a correction sub-algorithm executed in some
Cluster-Maker Algorithm environment. In such a scenario:
• The cluster-finding sub-algorithm will create the cluster object and record it in the TDS.
• The correction sub-algorithm will retrieve the cluster object from the TDS and perform some
correction (hence modifying the object in the TDS).
• The main Cluster-Maker algorithm that coordinates the various factions of the calorimeter
clustering will lock the object before returning control to the framework
• A downstream electron-finding algorithm can use these cluster objects in a readonly mode and
create a new electron object. Additional corrections may be determined and included in the
calculation of quantities of the final electron object, but the data of the original cluster object
cannot be changed. These additional correction, if necessary, must be preserved elsewhere.
• Note that it may be necessary for downstream algorithms to redo the clustering based on new
information that has become available only at a later stage. This is indeed possible - it may do
so, by creating a new cluster collection in the TDS. Since cluster collections in TDS can be
keyed (and later can also be associated with a history object), these are uniquely identifiable
objects in the TDS.
page 67