#13 Why are instances of partitioned classes being 'tanked'?

[Jade Support]

When using partitioned files you may see jommsg log entries similar to the following:

PDB: ## Transaction: 821762908 created instances of a partitioned class and overflowed cache
PDB: ## New instances of partitioned classes will be tanked until transaction commits...
PDB: ## Start Detanking Transaction: 821762908
PDB: ## End Detanking Transaction: 821762908

Broken down they can be explained like this.

The messages:

## Transaction: 821762908 created instances of a partitioned class and overflowed cache
## New instances of partitioned classes will be tanked until transaction commits...

...are logged by the database engine when it receives a new instance of a class mapped to a partitioned file before the transaction that created the object has committed AND the object does not have its partition index explicitly set.
Such objects are tanked because the destination partition cannot be determined until a partition method has been invoked and this is defined to occur when the transaction commits (and not before).

The database engine logs this event because it means additional processing overheads have been incurred and these are best avoided if possible.

A created object can be sent to the database before the creating transaction commits for a number of reasons, including:
a) The created object overflowed the client node object cache
b) Cache priority of the object was explicitly set to zero.

NB: case b) applies to JadeBytes data blocks unless overridden in the application using the JadeBytes::setCaching() method.

Tips to avoid tanking:
If the application is not making use of a partition method (by implementing ::autoPartitionIndex), then call the Object::setPartitionIndex() method in the object constructor (create method) to explicitly set the partition index. If an object’s partition index is explicitly set when it arrives at the database it will not be tanked.

If the application loads content into an exclusive JadeBytes property in the same transaction that created the parent object, then enable caching using the JadeBytes::setCaching() method before loading the content.

To obtain further information about the objects that have been tanked, enable pdb tracing by setting:

[JadeLog]
pdb=1

This causes counts of the different types of objects that were tanked (and detanked) to be logged between the following informational messages.

PDB: ## Start Detanking Transaction: 821762908
PDB: ## End Detanking Transaction: 821762908