PSE/PSE Pro introduces a new requirement for classes of objects that will be stored as keys in persistent hash tables: these classes must provide a suitable hashCode() method. PSE/PSE Pro and the Class File Postprocessor provide facilities for doing this conveniently.

PSE/PSE Pro provides a hash table class (COM.odi.util.OSHashtable) that is designed to provide good performance for persistent collections, although applications are free to use their own collection implementations. You can find an example of using PSE or PSE Pro with collections in

COM\odi\demo\collections

The default Object.hashCode() method supplies an identity-based hash code. This identity hash code might depend on the virtual memory address or some internal implementation-level metadata associated with the object. Such a hash code is unsuitable for use in an identity-based hash table because it would effectively be different each time an object was fetched in a transaction.

Providing an Appropriate Persistent Hash Code Method

Applications need to provide their own hashCode() methods for classes that define equals() methods that depend on the contents of instances rather than on object identity. If the equals() method just uses the == operator to compare the argument with this (or inherits Object.equals()), then it is identity-based and the hashCode() method provided by HashPersistent is appropriate. If the equals() method compares the contents of the objects, then it is contents-based and your application must supply a hashCode() method that returns the same hash code value for all objects whose contents make them return true when compared with the equals() method.

Perhaps your application does not store objects in persistent hash tables and you do not want the class file postprocessor (osjcfp) to put COM.odi.util.HashPersistent in your class hierarchies. In this case, applications are not required to have a persistence-capable class with a hashCode() method suitable for instances to be stored as keys in persistent hash tables. It is safe to not have one only if you are certain that instances of the class will never be stored as keys in persistent hash tables. To do this, make sure the class defines or inherits a hashCode() method that just calls the superclass's hashCode() method:

public int hashCode() { return super.hashCode(); } 

Storing Built-in Types in Persistent Collections

Java wrapper classes work nicely as keys because their hashCode() methods are based on the value of the object rather than its address.

You cannot store instances of java.util classes persistently because they are not persistence-capable. Instead, use the classes COM.odi.util.OSHashtable and COM.odi.util.OSVector, which are persistence-capable classes that support the same methods as the java.util.Hashtable and java.util.Vector classes.

Updated: 05/13/97 12:18:40