JDO utilizes some terminology used elsewhere (e.g. Java EE) but also introduces some terminology that may be new to people. Below is a glossary of some common terms that may be encountered.

    Term Definition
    application identity When the persistence of a class is defined in a MetaData file, the developer can decide that they want to control the identity of objects of that class. This is called application identity because the application has the control.
    attach/detach When you have an object of a class that is associated with a PersistenceManager it is referred to as being attached. If you want to stop persistence of that object you can detach the object. This has the effect that any changes to the object will not be persisted, and also that the object can be used outside transactions.
    datastore identity When the persistence of a class is defined in a MetaData file, the developer can decide that they want the identity of objects of that class to be defined by the JDO implementation. This is called datastore identity
    default-fetch-group (DFG) When a persisted object is retrieved from the datastore its fields can be retrieved with it, or optionally can be retrieved only when needed. If a field is in the default-fetch-group it will be retrieved when the object is retrieved. Some field types default to being in the default-fetch-group (e.g. primitives, wrappers to primitives, java.util.Date) and others (e.g. java.util.Set, java.util.List) don’t.
    embedded A field can be defined as embedded if it will be stored as a column in the table of its containing object.
    enhancer JDO 1.0.1 requires the use of a byte-code enhancer that takes the Java compiled classes and “enhances” them, adding in information to permit their use in a JDO environment.
    FCO JDO defines 2 main groups of Java objects. The first is those objects that have an identity. These are termed “First Class Objects” or FCO for short.
    Fetch Group JDO allows a user to define groups of fields that should be retrieved (fetched) at the same time. These are called a “fetch group”. The principal “fetch group” is the “default fetch group”, where JDO has rules for what fields are in this group. A user can define their own group, and make this active so that when objects of their type are retrieved, they have control over the fetching process.
    JDOQL JDO introduces its own Java-like query language as a datastore independent way of retrieving objects from the datastore. This is known as JDOQL (JDO Query Language).
    nondurable identity Where the objects of a class should be unique in the JVM but not in the datastore (where an RDBMS table doesnt have a PK for example).
    objectid class When an object of a class is persisted, it is assigned an object identity. When the developer has chosen to use application identity they can assign a class to represent this identity (as a primary key) - this is the object id class.
    optimistic transaction When working with long duration transactions it is undesirable to have locking and so the assumption is made that the data being updated by the transaction will not be modified by any other transaction during the course of the (optimistic) transaction. The data is checked just before commit to confirm integrity that no data has been changed. See also pessimistic transaction for the contrary type which provides locking.
    persistence-by-reachability When you call makePersistent() on an object, the object will be persisted and, in addition, any other objects reachable from that object (via relationships) will also be persisted. This is known as persistence-by-reachability. This process is repeated at commit() time when it checks whether these reachable objects are still reachable and, if not, removes them from persistence.
    persistence-aware When an class needs to access fields of a persistence capable class directly, it should be enhanced, and is referred to as “Persistence Aware”. If a class uses field accessor methods then it doesn’t need to become “Persistence Aware”.
    persistence-capable (PC) When an class is byte-code enhanced, and has valid MetaData, it is referred to as “Persistence Capable”. This means that it can be persisted by a JDO implementation.
    persistence-modifier When defining the persistence of a class, the developer can select particular fields to be persisted, and others not depending on their importance in the scope of their application. The persistence-modifier defines whether a field is persistent. If this tag is not specified JDO will assign defaults based on the field type (primitives, primitive wrappers, java.util.Data, persistence capable fields, etc are by default persistent).
    persistent This is an object state where the object is persistent in a datastore.
    pessimistic transaction This is the default transaction type in JDO, and is suitable for short-lived operations where there is no other blocking activity during the transaction. When data is accessed other transactions are locked out from accessing it until the transaction is complete. See also optimistic transaction for the contrary type which reduces locking.
    Requires Extent When the persistent of a class is defined, the developer decides if the object will be stored with its own identity (in its own table for example) or whether it will be stored as part of another object. If it will have its own identity, it will require and Extent.
    SCO JDO defines 2 main groups of Java objects. The second group is those objects that don’t have an identity. These are termed “Second Class Objects” or SCO for short.
    SQL JDO allows use of multiple query languages. One of these, for use with RDBMS datastores, is SQL.
    transient This is an object state where the object is not persistent.