When JDO manages an object, it
The JDO metadata determines whether a field is persistent, transactional, or 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.
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.
Although the specification is not entirely clear on this point, a reasonable interpretation holds that JDO
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
and the application changes the
object by adding or removing an element, the JDO implementation may, or may not, undo the change to the
object when restoring upon rollback. In this case, the
On all of these points, because the specification is not clear,
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 .
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
The application can determine which of the
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
interface type, then the implementation type for the object after it is
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.
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