14.3 Managed Relationships

Relationships in JDO are modeled as normal Java object references or collections of object references between persistence-capable classes. JDO does not define any additional semantics for relationships beyond that specified by the Java language. However, unlike normal Java applications, a JDO application cannot rely on automatic garbage collection for persistent objects. Instead, persistent objects must be explicitly deleted. In addition, many datastores support varying forms of referential integrity constraints.

To simplify application development, JDO 2.0 may add support for bi-directional relationships, cascade deletion, and even persistent garbage collection.

14.3.1 Bi-directional relationships

A Java object reference or collection of object references typically represent a one-way relationship. It allows an application to navigate from one object to another, but not back again. Bi-directional relationships support navigation in both directions.

Bi-directional relationships can be modeled in Java as a pair of object references (or collection of references), one in each way. However, this requires additional application logic to maintain both sides of the relationship; if one side of the relationship is changed, then this change must also be reflected in the other side.

JDO 2.0 may add support for implicit bi-directional relationships declared in the JDO metadata. The JDO implementation would then automatically manage both sides of the relationship without additional application coding. If the application changed one side of a relationship, the JDO implementation (perhaps in conjunction with the underlying datastore) would implicitly change the other side also.

The benefit of bi-directional relationships is that they allow an application to navigate in either direction without having to explicitly code anything.

14.3.2 Cascade delete

JDO requires explicit deletion of persistent objects. Unlike the persistence by reachability algorithm that is used when objects are made persistent, JDO currently does not support the concept of deletion by reachability, or what is more commonly known as cascade delete. If an application needs to ensure that referenced persistent objects are deleted when their parent is deleted, then it would typically need to implement the jdoPreDelete() method defined by the InstanceCallbacks interface.

JDO 2.0 may add the ability to define in the JDO metadata that a field reference's "dependent" persistent objects (persistent objects that are not referenced by any others) and should be implicitly deleted. Upon deletion, the JDO implementation would ensure that all dependent persistent objects were also deleted, avoiding the need for the application developer to implement the jdoPreDelete() method.

14.3.3 Persistent garbage collection

Cascade delete works well for situations in which dependent persistent objects are not shared. If they are shared, a simple cascade delete approach is not going to work because it is not possible to easily determine that a persistent object is not referenced by any other and can, therefore, safely be deleted.

JDO 2.0 may add support for a persistent garbage collection mechanism in which instances of specified persistence-capable classes that are no longer referenced by any others will be deleted automatically by the JDO implementation or underlying datastore.