Clustering

The ObjectStore data transfer between database server and clients is page-oriented. Therefore, the database object order strongly effects application performance.

The object clustering can be controlled for

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

In both cases, the clustering can be activated/deactivated step by step.

In terms of clustering, an object is either a master object or a slave object:

A master object is saved for a database segment, that has been defined for its class; a Cluster might be generated for the master object. The database layout (CLASSIX.INI) describes the information about the segment and about the Cluster, that is eventually being generated.

After the clustering has been deactivated completely, there are only master objects - this is the ClassiX^® default option.

A slave object database position defines another, connected Object, that has already been saved in the database. Such an object creation with CreatePersObject, CopyPersObject needs to be delayed up until a relation to an already existing database is established. Therefore, the specified InstantView^® commands first generate a (transient) CX_LAZY_CREATOR class.
Loading and unloading a database is different to this and described here.

Here, we would like to talk about rules which define, whether an object is a master or not.

These clustering rules have been split into categories. Each category is assigned to one bit; this will form a pattern that can be used to independently switch categories on and off.

This pattern is defined by the environment variable CX_CLUSTERING; default option is CX_CLUSTERING=0.

The following table shows all categories and the equivalent rules. Next to the bit in column 1, column 2 shows the according name.

Column three indicates, which classes can be slave objects. While for simple objects (such as objects of basic classes CX_DATE, CX_VALUE ...), the class is a sufficient criterion, there must be additional condition for all rather complex objects:

Bit	Category	Classes	Condition
1	BASIC	CX_NUMERIC..., CX_VECTOR_AMOUNT..., CX_TERM..., CX_FORMULA, CX_FCONDITION, CX_NAMED_FCONDITION, CX_CONDITIONED_BAG but not CX_NAMED_FORMULA	-
2	VALIDITY	CX_VALIDITY...	-
4	WRAPPER	CX_DESCRIPTIVE_REF, CX_OVERWRITING_REF	-
8	SLAVE_SEG	all	no separate object segment
16	ZEROPATTERN	CX_ATTRIBUTE_SET...	REP_pattern = 0
32	ZEROPATTERN	CX_PASSWORD..., CX_GENERAL_TERMS..., CX_CONDITION..., CX_ACCESS...	REP_pattern = 0
64	TXN	CX_TRANSACTION...	REP_pattern = 0 & (if ($ transaction ) transaction = master else master is a CX_TRANSACTION)
		CX_ALLOCATION...	REP_pattern = 0 & if (card allocators > 0) master Î allocators else true
128	MONITOR	CX_MONITOR... *except for* CX_COST_CENTER_ACCOUNT..., CX_COST_OBJECTIVE_ACCOUNT..., CX_COST_TYPE_ACCOUNT..., CX_FINANCIAL_ACOCUNT..., CX_DEBIT_ACCOUNT..., CX_CREDIT_ACCOUNT..., CX_EXPENSES_ACCOUNT..., CX_PRINT_MEDIA...	-
		CX_ACCOUNT...	if ($ owner) owner = master else true
		CX_DATA_CUBE...	Dimension[0] = master

A... means class A and all its derived classes
REP_pattern is the bit pattern, that defines its position inside the REP collection; either pre-defined by the class description in CLASSIX.ODB or via explicit specification in CreatePersObject
Conditions, that refer to the master object, only apply when loading/unloading, for CreatePersObject / CopyPersObject, a CX_LAZY_CREATOR will always be generated
Generating an object with CreatePersObject, there will be the additional condition REP_pattern = 0 for all categories. A transient object CX_LAZY_CREATOR cannot be inserted into a REP collection.