analysis fds | outage schedule | locked fds| data mgmt | server assignments

Search | Site Map .

What are Bridge Collections?

Since bridge technology provides a key to scalability required by the BaBar experiment, it is an important part of the BaBar database architecture. It introduces an extra layer on top of Objectivity's federations: so called bridge federation.

A bridge federation is used to store bridge collections. It can only contain bridge collections and tree collections (which are used to group bridge collections), no other data is allowed to be stored in a bridge federation. An attempt to create anything other than a bridge collection will result in an error.

A bridge collection contains a list of pointers to one or more slave (also called daughter) collections. It provides mapping between a collection name and location of its corresponding slave collection(s). A bridge collection can span unlimited number of slave federations, though in practice it usually references not more than just a couple.

Slave collections are stored in slave federations. A slave collection is a collection containing events. All collections that we used to have before bridge technology era now became slave collections. Their corresponding bridge collections have been created, and are available in the BaBar production environment.

Both analysis and simulation data is accessed through bridge federations. Running the commands 'physboot' and 'simuboot' will automatically set OO_FD_BOOT to point to the analysis and simulation bridge federations respectively.

Both reading and writing via bridge federation is transparent. All you need to do is to set OO_FD_BOOT to a bridge federation, and run your job in the usual way.

How does it work? Accesing collections in multiple federations via a bridge federation is achieved by switching of so called 'context'. By default, an Objectivity/DB process performs it's database operations within a single context. A context may only access one federation and all persistent references and cached objects are associated to that context. Bridge technology, dynamically creates and transparently switches multiple contexts, allowing access to multiple federations at the same time.

Phase I - reading

Reading via bridge federation, commonly referred as phase I, involves iterating over all slave collections of an input bridge collection, and reading events from each slave collection.

Phase II - writing

Writing events via bridge federation is often called phase II. Data is read from an input bridge collection (the same way as for Phase I), and output to an output bridge collection. An output bridge collection is created automatically. Also, an output slave collection is created for every input slave collection. Each newly created slave collection is automatilly attached to its output bridge collection.

By design, output slave collections will reside in federations corresponding to their input slave collections. This is required due to the fact, that an output collection may 'borrow' an event (that is point to original event or it's part, and cross-federation borrowing is not supported.

Phase III - All In One

Bridge technology brings additional complexity to the export process. Phase III has been design to deal with this problem.

Without phase III, in order to mirror a bridge collection at an external site, an administrator would have to either:

This may be quite time consuming if a bridge collection references slave collections that are stored across several federations.

Phase III allows us to read events from a bridge collection and copy them into a self-contained collection that resides in any federation we choose. The Phase III's output collection is a deep copy that does not borrow events or their components. A user may choose which data is copied, for instance it can extract only micro level data, or mini.

Also, we can force our job to output a collection to a new set of database files. This will prevent mixing events from two different output collections together. This option should be used wisely, if used without caution, it may significantly increased number of generated output database files.

Phase III all-in-one output streams are defined by specifying the output collection(s) in the form <collectionName@bootfile> . You may not mix phase III and non-phase III streams in the same job. The BdbCopyJobApp program in the BdbCopyJob package can be used to copy events to phase III streams:

Build and run BdbCopyJobApp using the appropriate script to copy the components you are interested in. Take a look at BdbCopyJob/CopyMicro.tcl which will configure BdbCopyJobApp to copy the micro-level components.

If you want to force the phase III stream(s) to write to new database files, add the following to the tcl script:

mod talk BdbEventOutput
set forceNewDatabases true

Summary of bridge federation related commands

All the commands listed below are supported by BdbInspector module.

Bridge collection creation:

collection create -b <bridge collection name>

Adding a slave collection to a bridge collection:

collection addTo <slave collection name>@<slave fd bootfile> <bridge collection name>

bridge collection name does not have to be the same as slave collection name.

Creating many bridge collections inside one transaction:

collection map <list of slave collection names space separated>@<slave fd bootfile>

The command will create a bridge collection for every slave collection on the list. The name of a bridge collection will be the same, as it's corresponding slave collection name.

Listing contents of a bridge collection:

collection contents -collection <bridge collection name>

Detaching a slave collection from a bridge collection

collection removeFrom <slave collection name>@<slave fd bootfile> <bridge fd name>


BaBar Public Site | SLAC | News | Links | Who's Who | Contact Us

Page Owner: Jacek Becla
Last Update: September 24, 2002