The following concepts should be understood by all database users and developers:

* The basic elements of Objy/DB are (the 3 first are "storage objects", the 2 last are "persistent objects"):
 

1. Federation: The "Federated Database" is "the mother of your databases". It contains the following set of files:

i) the databases files,
ii) a system database file (containing the Federation schema and the catalogue of the databases),
iii) the boot (ascii file with basic Federation info) and journal (transitory lock recording) files.

The Federation boot file is located at $OO_FD_BOOT [the official PHENIX Fed. is now at $PHENIX_FD_BOOT = phnxobjy.phenix.bnl.gov::/database/main_federation/PHENIX_26000.boot ]
and it is identified by a unique number ID [$OBJY_FDID = 26000 is the ID of the official PHENIX Federation].

2. Database: An Objy "database" is a file which contains a group of "containers" with data on them.
3. Container: A container groups "basic objects" physically clustered together in memory pages and on disk. It is the unit of locking (i.e. locking an object locks all the contiguous objects in the same container).
4. Basic Object: It is the fundamental unit of data stored in the DB. It is the representation in the DB of a class defined in your application (e.g. in Pdbcal). Objects are accessed using "smart pointers" called handles. Every object has an "Object Identifier" (OID) which identifies the D-C-P-S (Database-Container-Page-Slot) to which the object belongs to.

• There can be up to 64K DB/Fed., 64K containers/DB and 64K objects/container.

* Schema: The Federation schema is the model of the data stored in the Federation: the data classes + relations among them. PHENIX uses C++ classes which are defined in Data Definition Language (DDL) files, having a .ddl suffix (see 2. Developing with Objy.).

* Persistent or persistent-capable Object. A persistent-capable object is one that inherits from ooObj (see 3. Objy Administration Tools). [Persistence 1. <programming> A property of a programming language where created objects and variables continue to exist and retain their values between runs of the program.]

* File Server: Two sorts of file systems are supported by Objy:
 

1. Local file systems (Network File System) attached directly to the computer upon which the client application resides.
2. Remote file systems, attached to remote computers, accessed via the Advanced Multi-threaded Server (AMS) by a network protocol (AMS is a daemon that has to be installed on the file server machine by a system administrator, in PHENIX AMS host is at phnxobjy.phenix.bnl.gov).

AMS provides improved (asynchronous) write performance, whereas NFS provides only synchronous writing. FTO/DRO (replication) requires AMS. All file system protections are available using NFS while AMS is insecure.

The "page size" ($PAGE_SIZE = 8 K for PHENIX) is the Objy minimal unit of data transferred between a file server and the client application (the disk, the network and the application).

* Transactions: In databases, objects are accessed and retrieved (via their OID) through "transactions". In Objy, transactions allow multiple user access to objects while guaranteing the Atomicity-Consistency-Isolation-Durability properties (see the docs for details). Concurring access mode is MROW ("multiple read one write"). There are two types of permissions: "read" and "write" locks.

* Lock Server: This is a process running on a designated computer that manages concurrent access to the databases. When an application demands access to an object, Objy locks the container associated to the object via a daemon lock server process which can run on any machine in the network [in PHENIX it runs at phnxobjy.phenix.bnl.gov]. No data passes through the lock server, but it ensures that data within the federation is consistent and prevents simultaneous updates from multiple clients.

* Clustering or placement: 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 (i.e. modelling your application so that it does that) 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.