Basic information

Access to persistent objects for other instances (in multi-user operation) can be restricted in many ways, respectively rights can be granted for an instance of a persistent object (see also glo::EnLockMode). Individual objects or groups of objects can be locked. In principle, the individual locks must be removed using the corresponding unlock method with the same parameters.

It is also possible to query the current locks of other instances for each persistent object.

Note: The lock functionality also provides valid results in single user mode (locks can be set and queried as in multi-user mode). When developing an application, it is therefore not necessary to differentiate between multi-user and single-user operation.

Locking a persistent object

Every persistent object can be locked in the object database if the desired lock mode has not yet been restricted by another instance. This can be initiated either via glo::BasePersistent::lock (...) , glo::Reference::lock (...) or glo::Base::lockObject (...).

Another possibility is to use a glo::TPointerSet, a glo::TPointerList, a glo::TOndemandSet or a glo::TOndemandList. A lock can be set in these containers. Every object that is inserted into the container is automatically locked with the lock of the container, or released again when it is removed from the container.

Attention: A lock must always be released with the same parameters. This can be done with glo::BasePersistent::unlock (...), glo::Reference::unlock (...) or glo::Base::unlockObject (...).
If an object with a dependent referenced object is locked, for example with the glo::EnDeepMode glo::DM_SHALLOW, and the referenced object is replaced by another object, the originally referenced object remains locked and the newly referenced object is at least not affected by this lock, i.e. not locked. With an equivalent release of the lock, both the referencing and the originally referenced object are unlocked.

If necessary, referenced objects are also locked, if the keyword dependent (see also in table Glo-Data Types in column TypInfo) is set and the lock depth mode glo::EnDeepMode is corresponding.

This also applies to the following explanations if several objects are locked simultaneously.

Locking multiple persistent objects

A group of persistent objects can either be locked arbitrarily via a list of their glo::ObjID's using glo::Base::lockObjIdList (...) or by passing a subclass of glo::BaseLot to method glo::Base::lockLot (...) or by directly calling glo::BaseLot::lock(glo::EnLockMode eLockMode, glo::EnDeepMode eDeepMode) respectively glo::BaseLot::unlock(glo::EnLockMode eLockMode, glo::EnDeepMode eDeepMode) bzw. glo::BaseLot::unlock(const glo::LockSpecification & rLockSpecification).

Attention: A lock must always be released with the same parameters. This can be done with glo::Base::unlockObjIdList (...), glo::Base::unlockSet (...) or glo::BaseLot::unlock(glo::EnLockMode eLockMode, glo::EnDeepMode eDeepMode) or glo::BaseLot::unlock(const glo::LockSpecification & rLockSpecification).

Check object for locks or access possibilities

Whether a persistent object is locked with a certain mode can be directly communicated by the object itself via glo::BasePersistent::isLocked (...) or the glo::ObjID of the object to be checked is passed to glo::Base::isLockedObject (...).

Whether a persistent object can be read, written and/or deleted can be determined directly from the object itself via glo::BasePersistent::isPossible (...) or with glo::ObjID via glo::Base::isPossible (...).

In order to find out all the remaining possibilities of a persistent object in the object database, the methods glo::BasePersistent::getProcessingPossibilities (...) or glo::Base::getProcessingPossibilities (...) are available.