Managed and Unmanaged Fields

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.

• {% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

  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.