- 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 to access 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 may 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 the 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 the other database files it may reside on a NFS or AFS file system.
- Bridge federation
- A bridge federation is a BaBar-specific term....
- A catalog contains...
- Catalog Server
- A catalog server is a host where a federated database file is stored. Usually, it is accompanied by some metadata databases, like "management", "global", "evs_treenodes"
- Objects may 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 the mass store, and placing them on the same page will improve access by pre-fetching the second one when the first one 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.
- A 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).
- Developer federations
- See Test federations
- ...See also List of BaBar Database Domains
- Federated database file
- See Bootfile and federated database file
- Federated database
- 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
- File Server
- Two sorts of file systems are supported by the BaBar database. The first is local file systems, attached directly to the computer upon which 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.
- Journal file
- 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 touch these files.
- Journal server
- A journal server is a host where journal files are stored.
- Lock Server
- 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 a 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. More information see:...
- 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.
- OID server
- 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.
- See clustering
- Production federation
- This federation is that which contains the experiment data. It therefore contains both a schema catalog and a database catalog. One of the goals of the schema management is to ensure that this federation is robust that additions to 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, that allows 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.
- Reference federation
- This is equivalent to the Production Federation but 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.
- Release federation
- A release federation is created for each software release, and there is one such federation per release. Currently it is created for each release from scratch, but this will change in a production-based environment rather than the current development-based environment. In production, this federation will be 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.
- Test federations
- 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.
- Transient object
- A transient object exists only in 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