PSE/PSE Pro for Java API User Guide
Glossary
An active persistent object starts as an exact copy of the object that it represents in the database. PSE/PSE Pro initializes a hollow object so that it becomes an active object. This happens when an application calls the Persistent.fetch() or Persistent.dirty() method. If an application calls the Persistent.dirty() method (as opposed to the Persistent.fetch() method) on a hollow object, then the resulting active object can be modified.
Consequently, an active object is not necessarily identical to the object in the database that it represents. An application can read or update an active persistent object; a persistent object must be active for an application to read or update it.
A set of files that must be postprocessed together. Often, this is all the files in your application. In more complex applications, there might be multiple batches that each contain a library and then a batch of files that you write, which reference the libraries.
Persistent storage is organized into databases. Before a persistent object can be created, the database in which it is to be stored must exist, and this database must be opened by the process performing the creation. The database must also be opened by any processes accessing the object. A single application can open several databases at once. A single database can be accessed by many applications at once.
A simple deadlock occurs when one transaction holds a lock on a data item that another transaction is waiting to access, while at the same time the second transaction holds a lock on a data item that the first transaction is waiting to access. Neither process can proceed until the other does. PSE/PSE Pro detects and breaks deadlocks by aborting one of the transactions involved.
A hollow persistent object contains fields that are identical to the fields of the object in the database that the persistent object represents, but the fields have default values.
If the instances of a class can operate on persistent objects but an instance of the class cannot itself be stored in a database, the class is persistence-aware.
A persistence-aware class includes the annotations that call the fetch() and dirty() methods. It does not include the other annotations required for a class to be persistence-capable. Normally, you run the class file postprocessor to annotate a class so that it is persistence-aware. Occasionally, you manually annotate the class yourself.
A persistence-capable object has the capacity to be stored in a database. If you can store the instances of a class in a database then the class is persistence-capable and the instances of the class are persistence-capable objects.
The definition of a persistence-capable class includes specific annotations required by PSE/PSE Pro. After you compile class definitions, you run the PSE/PSE Pro class file postprocessor on the compiled classes to add the annotations that make the classes persistence-capable.
A persistent object is a representation of an object that is stored in a database.
After an application retrieves an object from the database, the application works with the persistent object in the Java environment. A persistent object always exists in one of three states:
session
A session is the software component that allows the use of the PSE/PSE Pro API. For a thread to use the PSE/PSE Pro API, it must issue a call that associates it with a session. Any number of threads can be serviced by a session.
A Java virtual machine that is running a PSE Pro application can run multiple sessions at the time. A Java virtual machine that is running a PSE application can run one session at a time.
A session can oversee
stale persistent object
A stale persistent object is no longer valid. Its fields have default values and it should not be used.
A persistent object might become stale after an application commits or aborts a transaction in which the active or hollow persistent object was accessible. When an application calls the ObjectStore.destroy() method, this causes the target of the destroy method to become stale.
An application must not try to read or update a stale object.
When an application commits a transaction, it stores in the database any transient objects that can be transitively reached from any persistent objects. This is the process of transitive persistence.
[previous]
doc@odi.com
Copyright © 1997 Object Design, Inc. All rights
reserved.
Updated: 05/13/97 12:20:35