Clustering

Clustering

With ObjectStore the data transfer between the database server and the clients is page-oriented. Therefore the arrangement of the objects in the database determines the performance of the applications to a high degree.

The clustering of the objects can be controlled for

• the object creation with InstantView® commands CreatePersObject, CopyPersObject
• the object creation when unloading/loading a database .

In both cases, clustering can be activated or deactivated in stages.

Under the aspect of clustering, an object is either a master or slave object:

A master object is stored in a segment of the database defined for its class; if Cluster(1) is specified in CLASSIX.INI for the class to be created, then a separate cluster is created for the master object. The information about the segment and any cluster to be created are described in the database layout(CLASSIX.INI).

Caution: Clustering objects can have a negative impact on performance if the clustered objects are held in sets or bags. See: Notes on clustering and collections

If clustering is completely deactivated, there are only master objects - this is the standard assumption in the ClassiX® system.

The position of a slave object in the database determines another object already stored in the database to which it is connected. The creation of such an object with CreatePersObject, CopyPersObject must be delayed until a relation to an object already existing in the database is established. Therefore the mentioned InstantView® commands first create a (transient) object of the class CX_LAZY_CREATOR.
The procedure for unloading / loading a database is different and is described there.

Examples of different clustering settings.

The decision diagram below illustrates where persistent objects are allocated.

Decision diagram for persistent allocation

Note: the following section describes the clustering when unloading/loading the database

Here, however, the rules that determine when an object is master and when it is not will be discussed.

The clustering rules have been grouped into categories - according to pragmatic considerations - and, by assigning a bit to each category, a pattern is obtained with which the categories can be switched on and off independently of each other.

This pattern is set with the environment variable CX_CLUSTERING; the default setting is CX_CLUSTERING=0.

The pattern can be changed at runtime by calling SetClusteringMode .

The following table shows the categories and the associated rules; in addition to the bit in column 1, a name was assigned in the second column.

Column 3 specifies which classes can appear as slave objects. While for elementary objects (e.g. the base classes CX_DATE, CX_VALUE ...) the class affiliation is sufficient as sole criterion, additional conditions are specified for more complex objects:

Dimension[0] = master

₁ = The condition only plays a role for the unloading of objects, because there you have to decide to which slave object it belongs, if it is connected to several master objects, so that it is not unloaded several times. When creating persistent objects, only the condition that the REP pattern must be 0 applies (exception: SLAVE_SEG, where the object may not define its own segment).

• A... means class A and all classes derived from it
• REP_pattern is the bit pattern that determines the classification of the object in the REP-Collection; either specified by the description of the class in CLASSIX.ODB or by explicit specification in CreatePersObject
• Conditions that refer to the master object master are only valid during unloading/loading, with CreatePersObject / CopyPersObject a CX_LAZY_CREATOR is always created
• If an object is created with CreatePersObject, the additional condition REP_pattern = 0 applies to all categories. A transient object CX_LAZY_CREATOR cannot be inserted into a REP collection.