10.4 Nondurable Identity

Some datastores cannot provide a unique identity that can be used to locate a specific piece of data. This limitation can be common in log files, history files, and similar files, where performance is a primary concern and there is no need for the overhead associated with managing a durable identity for each datastore instance. Objects are typically inserted into the datastore with transactional semantics, but they are not accessed by key. They may have references to instances elsewhere in the datastore, but often they have no keys or indexes themselves. They might be accessed by other attributes, and they might be deleted in bulk. JDO defines a nondurable identity type for use when accessing instances in such datastores.

Multiple objects in the datastore might have the same values; we refer to them as duplicate objects. An application may want to treat the duplicate objects individually. For example, the application should be able to count the persistent instances to determine how many have the same values. In addition, if the application changes a single field of one duplicate instance, exactly one instance has its field changed in the datastore. If multiple duplicate instances are modified in memory, then instances in the datastore are modified to correspond with the instances modified in memory. Similarly, if an application deletes a specific number of duplicate objects, it should delete this same number of objects in the datastore.

As another example, a single datastore instance using nondurable identity may be loaded twice into the JVM by the same PersistenceManager. Since there is no durable identity to distinguish instances from the datastore, two separate instances are instantiated in memory with two different nondurable identities, even though all of the values in the instances are the same. Only one of these instances can be updated or deleted. If only one instance is updated or deleted, then the changes made to that instance are reflected in the datastore at commit by changing the single datastore instance. However, if both instances are changed, the transaction fails at commit because changes to distinct instances in memory can be applied only to different datastore instances. In this case, there are multiple instances in memory and only one instance in the datastore.

Because nondurable identity is not visible in the datastore, it has special behaviors:

• After a transaction terminates (via commit or rollback), neither an instance in memory with nondurable identity nor its identity can be accessed, and any attempt to access them causes a JDOUserException to be thrown.

• A nondurable identity cannot be used in a different PersistenceManager instance than the one that issued it, and attempts to use it, even indirectly, throw a JDOUserException.

• The results of a query in the datastore always create and return new instances that are not already in the JVM. So, if the results of multiple queries contain the same instances in the datastore, additional instances of the datastore instances are instantiated in memory with the same values, but with different identities.

• makePersistent( ) succeeds even if another instance has the same values for all its persistent fields.

The implementation's class that implements nondurable identity has the following characteristics:

• It is public.

• All of its fields are public.

• The types of all of its fields are serializable.

• It has a public no-arg constructor, possibly the default constructor.

You should be aware that, at the time of this writing, there has been very limited support of nondurable identity (just one vendor supports it). The level of support may improve over time, but it obviously has not been a vendor priority.