Summary of Discussion

This is a summary of a discussion that took place on 25th March 1997 between David Quarrie, Pavel Binko and Steve Gowdy where we reviewed the issues about a transient or persistent event API. They are:

Transient API

This API uses the ProxyDict classes to present a fully transient view of the event to the end user. They locate objects within the event using the get<T> templated function and add new objects to the event using the put<T> function. Objects that are to become persistent are "markForStore"'d and the event itself is "store"'d which creates the appropriate persistent objects.

Advantages

• No (or little - see later) modifications to existing classes.
• Standard C++ class definitions & API.
• Conventional storage paradigm (new objects added to the event & then marked for storage).
• Allows the possibility of data compressed on the database (non-simple mapping between transient & persistent objects).
• Allows natural mapping of a hierarchical persistent event organisation into a flat transient one.
• Allows full use of Rogue Wave classes in transient classes.
• Allows easy "what-if" modifications to transient information without affecting the underlying persistent information (e.g. interactive event display).
• Allows transient objects to be used to cache information for performance advantages etc. without requiring that such caches be persistent.
• Compatible with the proposed solution for access to the environment (AbsEnv).

Disadvantages

• Twice as many classes (approximately, depending on details of mapping).
• Difficult to manage consistency between transient & persistent classes.
• Need to write store/fault handlers for every class pair.
• Need to replace pointer data members (T*) by DictPtr<T> data members.
• Requires memory to memory copies (transient <-> persistent).

Persistent API

This API still uses the ProxyDict classes to present a flat access to data objects within the event, but retrieves the persistent objects directly. Similarly, newly created objects are already persistent (although they must be explicitly attached to the event).

Advantages

• Single class per type.
• Simple to maintain.
• No memory to memory copies.

Disadvantages

• Significant modifications to user code. (HepRef(T), HepNew, HepDelete, etc.)
• Use of ddl files instead of hh files complicate dependency structure.
• Use of "new" operator by mistake creates persistent leaks (but easily tracked).
• Delete is irreversible (apart from transaction abort).
• Unconventional storage paradigm (newly created objects are already persistent - although not yet attached to the persistent event - and must be explicitly removed).
• Limited use of Rogue Wave classes (those supported by Objy under different names).
• Objectivity persistent Rogue Wave classes lag behind the transient ones (still v6 instead of v7). More importantly, Objectivity is migrating to STL-based classes and will drop support for the Rogue Wave classes.

Common problems

Neither solution fully addresses polymorphic lists without some overhead.

• The transient solution cannot create a persistent list from a transient one without losing the polymorphic information from the list items, unless some explicit RTTI is implemented (for example, from Robert Martin's book). Alternatively, each transient class could be required to implement a persistent( ) member function to create a persistent object. This will tightly couple the two classes and the dependencies need to be understood.
• The persistent solution only works with persistent lists of HepRef's to objects where each object is separately persistent. This incurs some overhead (12 bytes) per object. An alternative would be separate lists for each subclass, although this then requires the use of index offsets into each list. Messy.

Interim Conclusions

The advantages of the Transient solution outweigh those of the persistent solution. However, this means that we need to solve the polymorphism problem.

Action Items

Steve will design and implement a strawman transient/persistent class pair (based on his existing AbsEnv work) for a simple object (i.e. no references to other objects) and fault/store handlers so we can understand the dependency relationships and best way to encapsulate the fault/store handlers.

DB Home | BaBar Home | Computing | Reconstruction | Simulation | Search

DRQuarrie@LBL.Gov