State of the Persistent Interface

(report for the database mini-review 26 May 1998)

Introduction

The persistent of transient object and their recovery from the database is handled by the Converters classes, which used to be know as Writers. Over the last six months, apart from the change of name to better reflect their function, the Converters have been extended to deal with the following:

• split of logical and physical structures;
• more complex structure in transient and persistent objects.
• control of object placement.

Split of Logical and Physical Structures

The logical and physical structures of the database used to be the same, i.e. data logical grouped together in the event, in objects called Headers, were also grouped together within Databases inside the Objectivity Federation. The plan is now to group the data that will be used at the same time in the same Database (to minimize the number of open Databases), while the data that is generated together (and thrown away together when data is reprocessed) is grouped into the Headers. A more detailed discussion on this topic can be found elsewhere.

The impact of this change is that now two, rather than one, token must be handed to the Converter. One token specifies the persistent objects placement (see below) in the Federation, while the other specifics into which Header it should be placed.

Work to be done

We need to develop a list of appropriate headers. During the `transition' we have maintained a one-to-one correspondence between physical placement and Headers. Now that all the mechanics are in place we are ready to break this (probably after MDC II).

Complex Structures

The pool of available Converters has been expanded to allow more complex transient and persistent structures to be accommodated in the set of standard Converters.

Previously the standard converters only dealt with the storage of "simple" objects, plus the case of polymorphic objects. In this context "simple" means the following:

• For each occurrence in the transient event there was a persistent object.
• The persistent representation of a transient object could only be a single persistent object.
• A transient object was persisted as the class it appeared as in the transient event even if, in reality, it was a subclass of this class.

For polymorphic classes the last requirement was a problem, and this was handled by designing a Converter that could take a `Factory' that could work out the correct class to store. (One example of how this can be done using double dispatch is documented elsewhere. This concept of a `Factory' has been used to extend the power of `standard' Converters so that they can now deal with following cases:

• Even if a transient object has multiple occurrences in an event there is only one persistent object.
• The persistent representation of a transient object can now involve more than a single persistent class and these classes can be store in different databases (see below).

The impact of this change means that all but one class, the Event Tag (and maybe the DrcHits), can use the standard Converters to persistent themselves. This only requires the class designers to provide an appropriate Factory.

Work To Be Done

There is one final piece of code that need to be finished to allow a persistent representation to use multiple Databases (see below). The design for this is finished, it just needs to be implemented. The Tracking code then needs to be adapted to use the "new" standard converter so that the customized tracking Converter can be deprecated.

Control of Object Placement

Until now the placement of a persistent class was defined in the constructor of the appropriate Converter, and this was normally called in the relevant xxxBdbLoad::event routine. This required the author of this routine to decide, or be told, the component into which the persistent objects should be stored. The drawbacks with this approach were the following.

• The placement was usually hardwired into the xxxBdbLoad::event routine, which mean that it was difficult to change.
• The Database group, who should nominally be making these decisions, where not in control of this part of the code.
• The author of the xxxBdbLoad module had to have more knowledge of the database than was absolutely necessary.

To overcome these obstacles a there is a proposal to change the way Converters handle placement. The proposal is that, instead of passing in a token into the constructor indicating the component to be used by the converter, the token passed into the constructor should now indicate a placement policy object which the database group will manages. Here is a concrete example of how this will work. The Converter used to store the Track objects while specify "Tracks" as its placement token. The database group will have created a placement policy object which matched this token that contains the necessary number of clustering hints (in this case three) and this will be used by the Converter to locate the correct component for each persistent object. This approach requires a class designer to inform the database group how many persistent objects there are in the classes' persistent representation and discuss with them there expected usage so that each persistent object can be assigned to an appropriate component.

Work to be Done

The design for this extension is complete and just needs to be implemented. Once that has been done the database group need to confer with all the persistent class designers to set up appropriate placement policy objects. In the meantime there will be placement policies that equate to the current components, so that programs will continue to function as before.

Summary

There has been a number of changes to the design and function of the Converters over the last six months in an effort to improve their flexibility and to separate mechanics and policy of storage from the implementation of the persistent classes.

A design exists for the necessary changes, and the mechanics should be in place very soon. However the new design does require a number of policy issues to be defined, e.g. what Headers there will be; what placement policies there should be, and it is not expected that these will be needed for MDC II, though they should be in place for MDC II prime.