CreatePersObject

CreatePersObject

CreatePersObject(CX_xxxxx), CreatePersObject(CX_xxxxx, pattern)

parameters: Identifier of a class, BitPattern for Inheritance

Stack

Stack		Description
Stack(In)		-
Stack(Out)		the currently created (persistent) object

CreatePersObject(STACK), CreatePersObject(STACK, pattern)

parameters: BitPattern for Inheritance

Stack

Stack		Description
Stack(In)		Identifier of a class
Stack(Out)		the currently created (persistent) object

An object is created in the database (in persistent memory).
The definition of the database layout in CLASSIX.INI determines in which segment the object is stored and in which REP collections it is included. The settings made with SetLayer, SetDomain(WRITE) and SetPattern are decisive (see figure).
With the second parameter - pattern - the setting made in CLASSIX.INI or with SetPattern for this command call can be overridden.

In the ClassiX® system, various strategies for clustering the objects can be activated. There are rules that decide whether an object to be created is a master or a slave object.

Master objects know the location in the database where they are stored. For slave objects, the location in the database is determined only by an already stored object to which they are connected via a relation. For slave objects the object creation is delayed: CreatePersObject creates an object of class CX_LAZY_CREATOR. The "real" persistent object is only created when the CX_LAZY_CREATOR object is connected to another one, e.g. with instructions like SetReference, Insert, etc.

The following decision diagram illustrates how persistent objects are created in the database.

If you want to place an object instantiated as CX_LAZY_CREATOR in the database before the statements SetReference, Insert, etc., use the Instantiate function of the Object Manager.

If the clustering specification is active in the meta class (Cluster(1) set in the metafile), all objects for this class are created in a separate cluster and thus on a separate page.

If all clustering strategies are deactivated, there are only master objects.

Performance notes:

Before inserting the created persistent object into the REP collections, ClassiX automatically performs a BeginLock(WRITE) for deadlock avoidance. This command is relatively expensive and causes CreatePersObject x7 to run slower. In normal operation this slowdown is not noticeable by the user, because a CreatePersObject is still in the µs range. However, if massive objects are created (for example when filling the database), this difference in performance can be clearly measurable.

This mechanism can be deactivated in the system for such charge runs. Alternatively, by using an explicit BeginLock(WRITE) before starting a loading routine, it can be ensured that CreatePersObject does not execute its own BeginLock(WRITE) any more. Both approaches are comparably fast. The second approach still ensures that no deadlocks with other clients occur when creating objects and is therefore better suited for loading routines in live operation.

Created master objects are inserted into their REP collections by CreatePersObject. If the master objects are created in their own cluster (specification: Cluster(1)), then the REP collection should be declared as a LIST, since inserting clustered objects into a SET (the default for REP collections) leads to enormous performance problems. (See: Clustering and Collections)