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 (meaning each time an area handle is bound). The lock exists as long as an area handle is bound to an area instance version and it 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 method ATTACH_FOR_READ. 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, reads can be performed on the corresponding area instance version and its objects until the method DETACH 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

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

On an AS Instance, there can be a maximum of one exclusive lock on an area instance. An exclusive lock locks an area instance exclusively, which means that no parallel shared locks are possible on this version. Parallel reads are possible on the same area instance if area instance versioning is activated.

Once an exclusive lock is set in an internal session, reads and writes can be performed on the area instance version and its objects until the methods DETACH_COMMIT or DETACH_ROLLBACK are executed.

  • A new, empty area instance version is created when writes are performed.
  • The update does the following:
  • Binds the existing active version for writes in areas without versioning
  • Creates a copy of the active area instance version and binds it for writes in 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 and attempting to do this raises the exception CX_SHM_CHANGE_LOCK_ACTIVE. The method MULTI_ATTACH, on the other hand, 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 an internal session (except when using the statement LEAVE TRANSACTION (or the 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 using 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.