Shared Objects – States of Area Instance Versions 

Area instance versions can have the following states.

...

       1.      Building

An area instance version that has a change lock is being built. Change locks automatically create a building version.

       2.      Active

The area instance version whose build or update was last released using the DETACH_COMMIT method (and a database commit in the case of transactional areas) is active. All read locks are automatically set to the current active version.

       3.      Obsolete

If during read access the currently active version of the build, a new version becomes complete, then new version becomes active and the version that was previously active becomes obsolete. The read locks on the obsolete version remain until the read process is complete; new read locks for the area instance are always set on the active version, however.

       4.      Expired

Once the last read lock on an obsolete version is removed, the version expires; that is, it is deleted by the garbage collector. No locks can be set on expired versions and they are not considered when the version number is determined.

In an area without area instance versioning, there is always only one area instance version, which is available in one of the states mentioned above. In an area with versioning, there can be different states in an area instance at the same time:

·        Since there can be a maximum of one change lock on an area instance, at any time there is a maximum of one building version for each area instance.

·        There is a maximum of one active version for each area instance.

·        Depending on the maximum version number, several obsolete versions can exist in parallel.

 

In the simple case of a maximum of two versions, there can be a maximum of

¡        One active version and one building version

¡        One active version and one obsolete version

¡        One building version and one obsolete version.