CreatePersObject

CreatePersObject

CreatePersObject(CX_xxxxx), CreatePersObject(CX_xxxxx, pattern)

Parameter: Bezeichner einer Klasse, BitPattern für Inheritance

Stack

Stack		Beschreibung
Stack(In)		-
Stack(Out)		das gerade erzeugte (persistente) Objekt

 

CreatePersObject(STACK), CreatePersObject(STACK, pattern)

Parameter: BitPattern für Inheritance

Stack

Stack		Beschreibung
Stack(In)		Bezeichner einer Klasse
Stack(Out)		das gerade erzeugte (persistente) Objekt

Ein Objekt wird in der Datenbank (im persistenten Speicher) erzeugt.
Die Definition des Datenbanklayouts in CLASSIX.INI bestimmt, in welchem Segment das Objekt gespeichert und in welche REP-Collections es aufgenommen wird. Dabei sind die mit  SetLayer, SetDomain(WRITE) und SetPattern getroffenen Einstellungen bestimmend (siehe Abbildung).
Mit dem zweiten Parameter - pattern - kann die in CLASSIX.INI bzw. mit SetPattern getroffenen Einstellung für diesen Befehlsaufruf übersteuert werden.

Im ClassiX^®-System können verschiedene Strategien für das Clustering der Objekte aktiviert sein. Es gibt Regeln, die entscheiden, ob ein zu erzeugendes Objekt ein Master- oder ein Slave-Objekt ist.

Masterobjekte kennen den Ort in der Datenbank, wo sie gespeichert werden. Für Slave-Objekte bestimmt erst ein bereits gespeichertes Objekt, mit dem sie über eine Relation verbunden werden, den Ort in der Datenbank. Für Slave-Objekt wird die Objekterzeugung verzögert: CreatePersObject erzeugt ein Objekt der Klasse CX_LAZY_CREATOR. Das "richtige" persistente Objekt entsteht erst, wenn das CX_LAZY_CREATOR-Objekt mit einem anderen verbunden wird, z.B. mit Anweisungen wie SetReference, Insert, usw.

Das nachfolgende Entscheidungsdiagramm veranschaulicht, wie persistente Objekte in der Datenbank angelegt werden.

Will man ein als CX_LAZY_CREATOR instantiiertes Objekt noch vor den Anweisungen SetReference, Insert, usw.  in die Datenbank stellen, bedient man sich der Funktion Instantiate des Objekt-Managers.

Ist in der Meta-Klasse die Clustering-Angabe aktiv (Cluster(1) im Metafile gesetzt), werden alle Objekte für diese Klasse in einem eigenen Cluster und damit auf einer eigenen Page angelegt.

Wenn alle Clustering-Strategien deaktiviert sind, gibt es nur Master-Objekte.

 

Hinweise zur Performance:

ClassiX führt vor dem Einfügen des erzeugten persistenten Objekts in die REP-Collections automatisch ein BeginLock(WRITE) zur Deadlockvermeidung durch. Dieser Befehl ist vergleichsweise teuer und führt dazu, dass CreatePersObject x7 langsamer abläuft. Im Normalbetrieb ist diese Verlangsamung durch den Nutzer nicht wahrnehmbar, da ein CreatePersObject trotzdem noch im µs-Bereich liegt. Werden jedoch massiv Objekte anglegt (zum Beispiel beim Befüllen der Datenbank), dann kann dieser Performance-Unterschied deutlich messbar sein.

Für solche Ladeläufe kann dieser Mechanismus im System deaktiviert werden. Alternativ kann durch die Verwendung eines expliziten BeginLock(WRITE) vor dem Beginn einer Laderoutine sichergestellt werden, dass CreatePersObject kein eigenes BeginLock(WRITE) mehr ausführt. Beide Lösungsansätze sind vergleichbar schnell. Der zweite Ansatz stellt nach wie vor sicher, dass bei der Erstellung von Objekten keine Deadlocks mit anderern Clients auftreten und ist deshalb besser für Ladeläufe im Live-Betrieb geeignet.

Erzeugte Masterobjekte werden durch CreatePersObject in ihre REP-Collections eingefügt. Falls die Masterobjekte in einem eigenen Cluster angelegt werden (Angabe: Cluster(1)), dann sollte die REP-Collection als LIST deklariert werden, da das Einfügen von geclusterten Objekten in ein SET (der Default für REP-Collections) zu enormen Performance-Problemen führt. (Siehe: Clusterung und Collections)