Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Creating Objects and Values →  Shared Objects →  Shared Objects - Area Instance Versions 

Shared Objects - Area Locks

An area lock is set on the area instance version each time an area instance version is accessed, that is, each time an area handle is bound. The lock exists as long as an area handle is bound to an area instance version and rejects any attempts made to bind other area handles to the area instance. As long as no lock is set, a program cannot access area instances.

Other versions: 7.31 | 7.40 | 7.54

Shared Locks

A shared lock is set when an area handle is bound to an area instance version using the ATTACH_FOR_READ method. There can be a maximum of one shared lock on an area instance within an internal session. Across multiple sessions, there can be multiple shared locks on an area instance version.

Once a shared lock is set in an internal session, read access to the corresponding area instance version and its objects is possible until the DETACH method is executed.


Note

If a shared lock is always set immediately before an access and is then deleted again afterwards, note that the same version may not necessarily be accessed the next time. A shared lock is always set on the active area instance version.

Exclusive Locks

An exclusive lock is either a write lock or an update lock. A write lock is set if an area handle is bound to an area instance version using the ATTACH_FOR_WRITE method, and an update lock is set if an area handle is bound using the ATTACH_FOR_UPDATE method.

On an application server, there can be a maximum of one exclusive lock on an area instance. An exclusive lock locks an area instance exclusively, that is, no parallel shared locks are possible on this version. Parallel read accesses are possible on the same area instance if area instance versioning is activated.

Once an exclusive lock has been set in an internal session, read and change access to the area instance version and its objects is possible until the DETACH_COMMIT or DETACH_ROLLBACK methods are executed.

  • A new, empty area instance version is created with write access.
  • The update access:
  • Binds the existing active version for changing in the case of areas without versioning
  • Creates a copy of the active area instance version and binds it for changing in the case of areas with versioning

Within an internal session, a maximum of one exclusive lock can be set for an area instance, using ATTACH_FOR_WRITE and ATTACH_FOR_UPDATE. These methods cannot be used to set an exclusive lock if an exclusive lock already exists within the same internal session for any area instance version; attempting to do so raises the exception CX_SHM_CHANGE_LOCK_ACTIVE. On the other hand, the method MULTI_ATTACH can be used to set multiple parallel exclusive locks on multiple area instance versions.

Releasing Locks

Unless the method DETACH is used, shared locks are released automatically when an internal session ends. Exclusive locks must always be released explicitly using DETACH_COMMIT or DETACH_ROLLBACK. In the following situations, there must not be any exclusive locks for an area instance version, since this would produce the runtime error SYSTEM_SHM_CHANGE_LOCK_ACTIVE:

  • Closing of an internal session (except when using the statement LEAVE TRANSACTION (or function "/n")). The statement LEAVE TRANSACTION releases all exclusive locks using the method DETACH_ROLLBACK.
  • Database commit in the case of transactional areas.
  • Program calls with SUBMIT AND RETURN and CALL TRANSACTION in the case of transactional areas.

If all reference variables to an area handle are initialized and the area handle is then deleted by the garbage collector while it holds a lock, the lock remains and is not deleted. The area instance version can still be accessed, although exclusive locks can no longer be released. This produces the runtime error above.


Note

In transactional areas, note that an exclusive lock released using the method DETACH_COMMIT has to be released finally with a database commit before an internal session or program call (SUBMIT, CALL TRANSACTION, or LEAVE TO TRANSACTION) is closed.