Core Java Data Objects

JDO defines a number of different states in which an in-memory persistent object can be. Principally, these states are used by the JDO implementation to determine whether the fields of an instance need to be retrieved from the datastore and, if modified, whether they need to be written back. Together, these states represent an in-memory persistent object's lifecycle with respect to JDO.

Chapter 4 describes the object lifecycle states in greater detail; however, in general, only the following basic states need to be understood :

• Transient

• Persistent

• Hollow

Figure 3-4 shows a simplified state diagram for these basic lifecycle states:

Transient denotes a normal, non-persistent Java object. When an instance of a persistence-capable class is created, it starts life as being transient. By default, JDO does not do anything to manage transient instances.

When made persistent, either explicitly via makePersistent() or because an instance is reachable from another persistent object, an instance transitions to being persistent (it actually transitions to a "persistent-new" state). Five different states are used to represent persistence. These allow the JDO implementation to differentiate between whether an instance is new (" persistent-new "), has been modified (" persistent-dirty ") or deleted (" persistent-deleted "), and so on. All that really matters is that the instance is persistent, it has a JDO object identity, and its fields have been retrieved from the datastore within the context of the current transaction.

A hollow instance is also a persistent object (it has a JDO object identity); however, its fields have not yet been retrieved from the datastore, hence the term "hollow." The first time that a hollow instance is accessed, its fields are retrieved from the datastore within the context of the current transaction and the instance transitions to being persistent. (It actually transitions to " persistent-clean " to indicate the instance hasn't yet been modified.) Likewise, by default, after a transaction ends, all instances that are persistent transition to being hollow.

There are several optional features that provide support for transient instances being managed as transactional objects (changes to their fields being undone on rollback) and persistent objects being accessed outside of transactions. See Chapter 5 for more details.