Athena Developer Guide

Athena Chapter 14 Tools and ToolSvc Version/Issue: 2.0.0
from the data. A user can choose to set either behaviour at run time. The second property contains the
location in the data where the stored navigational information is located. Currently it must be set via the
jobOptions when necessary, as shown in Listing 14.9 for a particular implementation provided in the
Associator example. Two corresponding methods are provided for using the information from these
properties: followLinks() and whichTable().
Inverse Association - Retrieving information in the direction opposite to that of the links in the data is
in general a time consuming operation, that implies checking all the direct associations to access the
inverse relation for a specified object. For this reason Associators should keep a local copy of the
inverse associations after receiving the first request for an event. A few methods are provided to
facilitate the work of Associators in this case. The methods inverseExist() and
setInverseFlag(bool) help in keeping track of the status of the locally kept inverse
information.The method buildInverse() has to be overridden by concrete associators since they
choose in which form to keep the information and should be called by the associator when receiving the
first request during the processing of an event.
Locally kept information - When a new event is processed, the associator needs to reset its status to
the same conditions as those after having been created . In order to be notified of such an incident
happening the Associator base class implements the IListener interface and, in the constructor,
registers itself with the Incident Service (see section 13.9 for details of the Incident Service). The
associator’s flushCache() method is called in the implementation of the IListener interface in
the Associator base class. This method must be overridden by concrete associators wanting to do a
meaningful reset of their initial status.
14.4.1.3 A concrete example
In this section we look at an example implementation of a specific associator. The code is taken from
the LHCb Associator example, but the points illustrated should be clear even without a knowledge
of the LHCb data model.
The AxPart2MCParticleAsct provides association between physics analysis particles
(AxPartCandidate) and the corresponding Monte Carlo particles (MCParticle). The direct
navigational information is stored in the persistent data as short-cuts, and is retrieved in the form of a
SmartRefTable in the Transient Event Store. This choice is specific to
AxPart2MCParticleAsct, any associator can use internally a different navigational mechanism.
The location in the Event Store where the navigational information can be found is set in the job options
via the “DataLocation” property, as shown in Listing 14.9.
Listing 14.9 Example of setting properties for an associator via jobOptions
ToolSvc.AxPart2MCParticleAsct.DataLocation = "/Event/Anal/AxPart2MCParticle";
page 134
In the current LHCb data model only a single MCParticle can be associated to one
AxPartCandidate and vice-versa only one or no AxPartCandidate can be associated to one
MCParticle. For this reason only the i_retrieveDirect and i_retrieveInverse
methods providing one-to-one association are meaningful. Both methods verify that the objects passed
are of the correct type before attempting to retrieve the information, as shown in Listing 14.10. When
no association is found, a StatusCode::FAILURE is returned.