JDO utilizes some terminology used elsewhere (e.g J2EE) 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 primtives, 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. JPOX provides its own byte-code enhancer to
perform this, but also supports classes enhanced using the JDO reference implementation (RI) enhancer. |
| 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. |
| 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). |
| 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-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 shortlived 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. |
| transient | This is an object state where the object is not persistent. |
