Persistent Objects | Objectivity Developer Network (original) (raw)
What are Objectivity/DB persistent objects?
Persistent objects are the fundamental logical units of data storage in an Objectivity/DB federated database.
Persistent objects are created by applications. Each persistent object has an object identifier (OID) and is an instance of a class. The class may be defined in an object-oriented programming language, or it may be a class defined by Objectivity/DB (for example, ooObj). In either case, the class is described in the federated database's schema.
A persistent object continues to exist and retain its data beyond the duration of the process that creates it. In contrast, a transient object exists only within the memory of the process that creates it; when that process terminates, the transient object ceases to exist.
How does Objectivity/DB store persistent objects?
Objectivity/DB stores persistent objects on storage pages. A storage page is the minimum unit of:
- File growth. When Objectivity/DB creates a new container in a database or extends a container to accommodate new basic objects, the space is added as a whole number of storage pages.
- Physical transfer to and from disk and across networks. When an application reads data from a file, one or more whole storage pages are transferred into virtual memory. Conversely, when an application commits modifications to data, one or more whole storage pages are transferred back to disk.
The size of a storage page is configurable for each data file and is set when a database or external container is created; once set, the page size cannot be changed. A federated database maintains a default storage-page size, which is used for its system database and for any databases created without an explicit page size. You set the default storage-page size when you create the federated database.
Storage pages are usually sized so that one or more typical persistent objects will fit within a single storage page; each such small object occupies a slot on the page. A large object spans multiple storage pages, where one of these pages (the header page) contains overhead information and links to other pages containing data. A storage page containing a small object or the beginning of a large object is also called a logical page. Logical pages (and their slots) have integer identifiers that are used in the identifiers of persistent objects. In a data file containing only small objects, every used storage page is also a logical page. In a data file containing many large objects, the logical pages are a subset of the used storage pages.
When Objectivity/DB reads a persistent object from disk, it places the storage page(s) containing the object into the Objectivity/DB cache. The cache is memory allocated and managed by Objectivity/DB to provide fast access to persistent objects. The cache consists of buffer pages, which are sized to match the storage pages being accessed.
In a multithreaded application, each thread that executes a separate series of transactions has its own Objectivity/DB cache in the process’s address space.
What is an objects OID?
The identifier for a basic object is called its object identifier or OID. An object identifier corresponds to the exact storage location of the object within the federated database; it is unique within the entire federated database, not just within the object’s container. An object’s OID can change during the lifetime of the object only if the object is moved to a different container. After an object is moved or deleted, its previous object identifier is reused for any new object that is created in the former location of the moved or deleted object.
The identifier of a basic object contains enough information to distinguish it from every other basic object within the entire federated database, not just within the object’s container. An object identifier is 64 bits long and is composed of four 16-bit fields in the following string format:
D-C-P-S
where
D Database identifier.
C Container identifier.
P Logical page number in the container. A logical page is a storage page containing one or more small objects or the header information for a large object.
S Slot number on the page. A slot is the portion of a logical page in which a single small object is stored. The slot number for a large object is always 0.
Can I lock a persistent object?
No. Containers are the smallest unit of locking for persistent objects; when an application requests a lock on a basic object, the lock is granted on the container in which the basic object resides. In effect, locking a single basic object locks all of the basic objects in the same container.
When an application requests a lock on a persistent object, the lock server applies the transaction’s concurrent-access policy to determine whether the requested lock is compatible with any existing locks on the relevant container.