Show TOC

Background documentationShared Objects - States of Area Instance Versions Locate this document in the navigation structure

 

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 to the currently active version of the build, a new version becomes complete, the 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, there is a maximum of one building version for each area instance at any given time.

  • 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.

Example Example

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

One active version and one obsolete version

One building version and one obsolete version

End of the example.