Program guide > Access data with client applications > Retrive entities and objects (Query API)

Use objects other than keys to find partitions (PartitionableKey interface)

When an eXtreme Scale configuration uses the fixed partition placement strategy, it depends on hashing the key to a partition to insert, get, update, or remove the value. The hashCode method is called on the key and it must be well defined if a custom key is created. However another option is to use the PartitionableKey interface. With the PartitionableKey interface, you can use an object other than the key to hash to a partition.

Use the PartitionableKey interface in situations where there are multiple maps and the data you commit is related and thus should be put on the same partition. WebSphere eXtreme Scale does not support two-phase commit so multiple map transactions should not be committed if they span multiple partitions. If the PartitionableKey hashes to the same partition for keys in different maps in the same map set, they can be committed together.

You can also use the PartitionableKey interface when groups of keys should be put on the same partition, but not necessarily during a single transaction. If keys should be hashed based on location, department, domain type, or some other type of identifier, children keys can be given a parent PartitionableKey.

For example, employees should hash to the same partition as their department. Each employee key would have a PartitionableKey object that belongs to the department map. Then both the employee and department would hash to the same partition.

The PartitionableKey interface supplies one method, called ibmGetPartition. The object returned from this method must implement the hashCode method. The result returned from using the alternate hashCode will be used to route the key to a partition.

Parent topic:

Retrive entities and objects (Query API)

Related concepts

Query data in multiple time zones

Insert data for different time zones

Use the ObjectQuery API

EntityManager Query API

Reference for eXtreme Scale queries

Query performance tuning