Managed and Unmanaged Fields

When JDO manages an object, it manages the individual fields of that object. For JDO, there are three kinds of fields in the application data class:

• Persistent fields

• Transactional fields

• Unmanaged fields

The JDO metadata determines whether a field is persistent, transactional, or unmanaged.

What Types of Fields Can Be Unmanaged?

Any type of field can be unmanaged. JDO imposes no constraints on unmanaged fields.

Fields that are declared with the static or final keywords must be unmanaged. JDO ignores static fields because they do not contain dynamic object state.

JDO's architecture does not allow it to manage final fields. JDO uses the no-arg constructor of the application data class to create the object before it reads the values of persistent fields from the datastore. Since the values of final fields can be assigned only in field initializers or constructors, there is no way for JDO to load the value of a final field from the datastore.

What Types of Fields Can Be Transactional?

Except for static and final fields, any type of field can be transactional. The values of a transactional field are never stored or found in the datastore. JDO includes the values of transactional fields in the before-image that JDO saves when the transactional object becomes dirty and the transaction's RestoreValues property is true.

Restoring Transactional Fields on Rollback

Although the specification is not entirely clear on this point, a reasonable interpretation holds that JDO restores on rollback the field values of any type of transactional field when the transaction's RestoreValue property is true. It should not matter whether the implementation offers strong or weak supports for the RestoreValues property. JDO should restore the field's value when its type is a primitive type, an immutable class, a supported mutable system class, an unsupported mutable system class, or an application data class. In other words, JDO should restore the field's value in all cases.

Beyond restoring the transactional field's value, JDO does not impose any additional requirements. Although JDO defines persistence by reachability for persistent fields, it does not define transactional by reachability for transactional fields. If a transactional field refers to a JDO-transient application data object, and the application changes that object without changing the transactional field that refers to that object, the restore on rollback may not (and probably will not) undo the change. If a transactional field refers to an object that is an instance of an unsupported mutable system class and the application changes that object, the restore on rollback may not (and probably will not) undo the change.

In the case of transactional fields that refer to objects of supported mutable system classes, JDO may, or may not, undo the changes to the objects upon restore. For example, if the transactional field's type is HashSet and the application changes the HashSet object by adding or removing an element, the JDO implementation may, or may not, undo the change to the HashSet object when restoring upon rollback. In this case, the likelihood is more that it will than it will not.

On all of these points, because the specification is not clear, implementations may differ.

What Types of Fields Can Be Persistent?

All JDO implementations must support persistent fields that have any of the following primitive or reference types:

• Any enhanced application data class.

• All eight primitive types: char, byte, short, int, long, float, double, and boolean.

• The eight immutable wrapper classes of primitive types in the java.lang package: Character, Byte, Short, Integer, Long, Float, Double, and Boolean.

• The immutable class String in the java.lang package.

• The immutable class Locale in the java.util package.

• Either of the two immutable classes in the java.math package: BigDecimal and BigInteger.

• Either of two mutable classes in the java.util package: Date and HashSet.

• Either of two interface types in the java.util package: Collection and Set.

• The Object class in the java.lang package. The implementation may, and probably will, restrict the types of objects that may be assigned to an Object field.

• Interface types other than the collection interfaces (Collection, List, Map, Set, etc.). The implementation may, and probably will, restrict the types of objects that may be assigned to the field.

When the persistent field's type is an Object or an interface (other than the collection interfaces), the implementation is likely to require that objects assigned to the field must be instances of one of the other supported classes. If the implementation's requirements are not met when the assignment is made, the implementation throws a ClassCastException.

Optionally Supported Types for Persistent Fields

JDO specifies a short list of types that the implementation may optionally support for persistent fields.

• Any of seven classes in the java.util package: Hashtable, Vector, ArrayList, LinkedList, HashMap, TreeMap, TreeSet

• Either of two interface types in the java.util package: Map and List

• Arrays

The application can determine which of the preceding optional field types are supported for a particular implementation by calling the supportedOptions method in the PersistenceManagerFactory interface. Chapter 6 discusses the PersistenceManagerFactory interface.

The supported collection types always support collections of application data objects. At its option, the JDO implementation may also support collections of supported system objects, such as collections of collections, collections of dates, collections of strings, and so forth.

When the persistent field is a Collection, Map, Set, or List interface type, then the implementation type for the object after it is fetched from the datastore may not be the same as the implementation type that was stored. For example, the application may make a new application data object persistent that has a List field to which has been assigned an object of type LinkedList. When the object assigned to the field is later fetched from the datastore, it may come back as an ArrayList. If it is important to the application that the object assigned to the list field always be a LinkedList object, then the field's type should be LinkedList rather than List.

If the implementation supports arrays, it supports arrays of all supported persistent types except arrays, collections, and maps. Even when the implementation supports arrays, it may decline to support arrays of arrays, arrays of collections, and arrays of maps.

Support for Fields That Implement Serializable

If a field is persistent, it may be, or may not be, serializable. If a field is serializable, it may be, or may not be, persistent. JDO does not connect the two properties in any way. On the other hand, a JDO implementation may support any type as persistent as long as the class implements the java.io.Serializable interface. In this case, the JDO implementation is going beyond what the JDO specification requires or defines. By supporting any serializable class as persistence capable, the implementation is allowing the application to define embedded objects that are stored in the datastore as second class objects.

Fields that are persistent because they are serializable have several drawbacks. Their use introduces a portability constraint because not all implementations support such fields. Their contents may be opaque in the datastore because the datastore usually stores these objects as byte fields. Without deserializing the byte field, other datastore tools cannot manipulate the values contained within the object. The JDO query language does not provide a means to access the fields within these objects, and the implementation may, or may not, support using the JDOQL equality operators (== and !=) on these fields.