Grundsätzliches

Es kann der Zugriff auf persistente Objekte für andere Instanzen (im Mehrbenutzerbtrieb) vielfältig eingeschränkt bzw. Rechte für eine Instanz an einem persistenten Objekte eingeräumt werden (siehe auch glo::EnLockMode). Es können einzelne Objekte oder auch Gruppen von Objekten gesperrt werden. Grundsätzlich müssen die einzelnen Sperren mit der korrespondieren unlock-Methode mit gleichen Parametern wieder aufgehoben werden.

Es besteht zudem die Möglichkeit, für jedes persistente Objekt die aktuellen Sperren anderer Instanzen abzufragen.

Zu beachten: Die Sperrfunktionalität liefert auch im Einzelbenutzerbetrieb valide Ergebnisse (es können wie im Mehrbenutzertrieb Sperren gesetzt und abgefragt werden). Bei der Entwicklung einer Applikation braucht also nicht extra zwischen Mehr- und Einzelbenutzerbetrieb unterschieden werden.

Ein persistentes Objekt sperren

Jedes persistentes Objekt kann in der Objektdatenbank gesperrt werden, wenn der gewünschte Sperrmodus noch nicht von einer anderen Instanz eingeschränkt wurde. Dieses kann wahlweise über glo::BasePersistent::lock (...) , glo::Reference::lock (...) oder glo::Base::lockObject (...) initiiert werden.

Eine weitere Möglichkeit besteht, indem ein glo::TPointerSet, eine glo::TPointerList, ein glo::TOndemandSet oder eine glo::TOndemandList genutzt wird. In diesen Containern kann eine Sperre gesetzt werden. Jedes Objekt, welches man in den Container einfügt wird automatisch mit der Sperre des Containers gesperrt, bzw. wieder freigegeben wenn aus dem Container entfernt.

Achtung: Eine Sperre muss immer mit den gleichen Parametern aufgehoben werden. Das kann wiederum wahlweise über glo::BasePersistent::unlock (...), glo::Reference::unlock (...) oder glo::Base::unlockObject (...) geschehen.

Ggf. werden referenzierte Objekte mitgesperrt, wenn über dass Schlüsselwort dependent (siehe auch in Tabelle Glo-Datentypen in Spalte TypInfo) eingestellt und der Sperrtiefenmodus glo::EnDeepMode dementsprechend ist.
Wenn ein Objekt mit einem dependent referenzierten Objekt z.B. mit dem glo::EnDeepMode glo::DM_SHALLOW gesperrt, und das referenzierte Objekt durch ein anderes Objekt ausgetauscht wird, bleibt das ursprünglich referenzierte Objekt weiterhin gesperrt und das neu referenzierte Objekt ist zumindest von dieser Sperre nicht betroffen, also nicht gesperrt. Bei einer äquivalenten Aufhebung der Sperre, werden aber das referenzierende wie auch das ursprünglich referenzierte Objekt entsperrt.

Dieses gilt auch für die folgenden Erläuterungen, wenn mehrere Objekte gleichzeitig gesperrt werden.

Mehrere persistente Objekte sperren

Eine Gruppe von persistenten Objekten kann entweder wahlfrei über eine Liste von deren glo::ObjID's über glo::Base::lockObjIdList (...) oder mit Übergabe einer Unterklasse von glo::BaseLot an Methode glo::Base::lockLot (...) bzw. den direkten Aufruf von glo::BaseLot::lock(glo::EnLockMode eLockMode, glo::EnDeepMode eDeepMode) bzw. glo::BaseLot::lock(const glo::LockSpecification & rLockSpecification) gesperrt werden.

Achtung: Eine Sperre muss immer mit den gleichen Parametern aufgehoben werden. Das kann wiederum wahlweise über glo::Base::unlockObjIdList (...), glo::Base::unlockSet (...) oder glo::BaseLot::unlock(glo::EnLockMode eLockMode, glo::EnDeepMode eDeepMode) bzw. glo::BaseLot::unlock(const glo::LockSpecification & rLockSpecification) geschehen.

Objekt auf Sperren bzw. Zugriffsmöglichkeiten prüfen

Ob ein persistentes Objekt mit einem bestimmten Modus gesperrt ist, kann direkt das Objekt selbst über glo::BasePersistent::isLocked (...) mitteilen oder es wird die glo::ObjID des zu prüfenden Objekts an glo::Base::isLockedObject (...) übergeben.

Ob ein persistentes Objekt gelesen, geschrieben und/oder gelöscht werden kann, erfährt man direkt vom Objekt selbst über glo::BasePersistent::isPossible (...) bzw. auch mit glo::ObjID über glo::Base::isPossible (...).

Um alle noch vorhandenen Möglichkeiten eines persistenten Objektes in der Objektdatenbank zu erfahren, stehen die Methoden glo::BasePersistent::getProcessingPossibilities (...) bzw. glo::Base::getProcessingPossibilities (...) zur Verfügung.