Partitioning by Period

It is convenient and efficient if data can be partitioned based on the time it is first created. Examples of the kind of data that are candidates for this style of partitioning are application audit trails, transactions, messages, and events.

The objects used to represent these kinds of data are typically created once and are never (or seldom) updated. This kind of data can be partitioned based on the period in which it was created.

To implement a temporal partitioning scheme

Select a suitable period for partitioning (daily, monthly, quarterly, or yearly).
Enable partitioning on the map file of the class (with the modulus set to 1).
Do not re-implement the autoPartitionIndex method.
Call the setPartitionIndex method to explicitly set the partition index to zero (0).
Implement a mechanism that creates a new partition at the start of each new period.

Step 4 of this instruction avoids the overhead of invoking the autoPartitionIndex method defined on the Object class during transaction commit processing (see "Automatic Partitioning", later in this chapter).

With partition modulus set to 1, the creation window is restricted to a single partition (the latest partition), which means that all new objects can be created only in the latest partition. Attempts to set a partition index other than zero (0) will fail, resulting in the aborting of the transaction.

Immediately prior to the commencement of a new period, the application creates new partitions for related classes.

The following code fragment shows the instructions required to create new partitions for the Order and OrderItem classes.

// execute just before midnight at end of current period
beginTransaction;
Order.createPartition;
OrderItem.createPartition;
// execute just after midnight at start of next period
commitTransaction;

In this code fragment, the createPartition method creates a new partition for the class and returns the unique partition identifier. The createPartition operation is audited within a database transaction, ensuring that it is atomic and recoverable.

You can make multiple related createPartition operations atomic, by containing them in the same database transaction.

The following restrictions apply to the use of the createPartition method.

Partitions can only be created within a transaction
No other partition creation operation can be in progress
Persistent objects cannot be created or updated in the transaction that creates a partition
Persistent objects cannot be created in a partitioned file by any user while a new partition for that file is being created

For a production application, developers should implement a synchronization mechanism to prevent the creation of objects stored in a partitioned file while a new partition is created.