An AMS (Advanced Multithreaded Server) is the equivalent of a network file server (NFS) for Objectivity/DB databases. Much like NFS, when a client requires access to an Objectivity/DB database, the client connects to the server that holds the databases using a predetermined TCP/IP port number. The connection is maintained with the server until the client closes the connection. While the client is connected, the client can read from or write into a database, as well as perform other database related activities.
Bootfile and federated database file
The Federated Database File contains schema definitions and database catalog for a federation. By BaBar convention it is called BaBar.FDDB and is located on the catalog server. The boot file is a file that describes the federated database configuration, the location and file server of the federated database file, the federated database ID, lock server node, and other parameters describing the federation. In principle the Boot File is the only file that must be directly visible to the client applications and is used to bootstrap the applications. By BaBar convention the boot file is called BaBar and should reside on a file system that is visible to all desired client computers. Unlike other database files it can reside on a NFS or AFS file system.
A bridge collection is a collection that binds a collection name with a slave federation containing the corresponding collection of events. It is a BaBar-specific term.
A bridge federation is a BaBar-specific term. It is a federation that contains bridge collections.
A catalog server is a host where a federated database file is stored. Usually, it is accompanied by some metadata databases, such as management, global, evs_treenodes.
Objects can be created close together in the federation, based on their predicted access patterns. Thus, if two objects are typically accessed together, clustering them in the same database will minimize tape-mounts in mass store, and placing them on the same page will improve access by pre-fetching the second one when the first is accessed, minimizing I/O traffic.
Clustering hint server (chs)
A clustering hint server is a CORBA server developed by the BaBar Database Group. It centrally manages data placement.
This term is Objectivity-specific. A container is a logical grouping of persistent objects. Persistent objects within a container are physically clustered together in memory and on disk. A container is also a unit of locking: when one object is locked, the whole container is locked.
The word database has slightly different meanings in different database systems. In Objectivity, a database is a set of containers. It physically maps to a single file. Each database is identified by a database ID (DBID).
See Test federations
The BaBar system has been structured into several independent pieces, with regards to its logical aspects. The outermost layer comprises of several logical domains. These include: Event Store, Conditions Databases, Online Databases, Spatial Databases, Temporal Databases.
Federated database file
See Bootfile and federated database file
This term is Objectivity-specific. It is a unit of administrative control for Objectivity/DB. It consists of database files, a database catalog, and a schema. Each federation is identified by a federated database ID (FDID).
See Federated database
Two types of file systems are supported by the BaBar database. The first is local file systems, attached directly to the computer where the client application resides. The second is remote file systems, attached to remote computers. Such file systems are accessed via the AMS by a network protocol.
A journal file is an internal Objectivity/DB file, where Objectivity/DB automatically records all modifications. Each update transaction has one corresponding journal file. Read transactions are not logged. Never manually alter or delete journal files. Only Objectivity/DB tools/code may be used with these files.
A journal server is a host where journal files are stored.
A lock server is a process that manages concurrent access to the databases. No data passes through the lock server, but it insures that data within the federation is consistent; it prevents simultaneous updates from multiple clients. Within BaBar, we run a dedicated lock server for each production federation.
On Object Oriented Database Management System (ODBMS) integrates object programming language capabilities with database capabilities. It makes objects appear as programming language objects; it extends the language with transparently persistent data, concurrency control, data recovery, associative queries, and other database capabilities.
Object identifier (OID) is a unique set of numbers that allows Objectivity/DB to locate and manage persistent objects. An OID is 64 bits in length and it is composed of four 16-bit fields in the format of: DB-OC-PG-SL, where
DB - database identifier (dbid)
OC - container identifier
PG - logical page number
SL - logical slot number on the pageOID value do not change during the lifetime of an object.
An OID server is a CORBA server developed by the BaBar Database Group. It centralizes locating condition objects.
OO_FD_BOOT is an environment variable that stores location of a bootfile.
Persistent object (or persistent-capable object)
A persistent object is an object that continues to exist and retains its data beyond the duration of the process that creates it.
This federation contains the experiment data. It therefore contains both a schema catalog and a database catalog. One of the goals of schema management is to ensure that this federation is robust, that additions to the schema do not affect the existing data, and that changes to existing schema do not affect other schema and data. There is only a single production federation in the experiment.
Pud ("Perl Universal Daemon") is a stand-alone daemon, which allows you to perform file system related operations on a remote host.
One persistent object may reference another persistent object. Such references may span databases if the two objects reside within different databases.
This is equivalent to the production federation but it only has a schema catalog. This catalog is identical to that of the production federation. The main role of this federation is to ensure that any problems are caught at this stage rather than in the production federation itself. All schema in this federation have been assigned explicit and unique schema ids. There is only a single reference federation in the experiment.
A release federation is created for each software release, and there is one such federation per release. This federation is based upon the reference federation as a starting point for the release build.
A database schema is a description of persistent classes. BaBar uses C++ classes, which are defined in Data Definition Language (DLL) Files, having a .ddl suffix. A schema is stored persistently in a federation.
These are the federations against which developers create and test new classes in their test releases. Each such federation is based upon the release federation for the corresponding release. Multiple developer federations can exist simultaneously.
A transaction is a unit of work that an Objectivity/DB application can apply to a database. It contains one or more logically related operations that create, access, or modify persistent objects. Every interaction with persistent objects must occur within a transaction.
A transient object exists only in the memory of the process that creates it. When that process terminates, the transient object ceases to exist.
BaBar Public Site | SLAC | News | Links | Who's Who | Contact Us
Page Owner: Jacek Becla
Last Update: June 13, 2002