Get Example source ABAP code based on a different SAP table
ABAP_SHM - 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 it rejects any attempts to bind other area handles to the area instance. As long as no lock is set, a program cannot access area instances.
Read Locks A read 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 read lock on an area instance within an ABAP_ISESS . Across multiple sessions, there can be multiple read locks on an area instance version. Once a read lock has been set in an ABAP_ISESS , reads can be performed on the corresponding area instance version and its objects until the method DETACH is executed.
Latest notes: If a read lock is always set immediately before an access, and then deleted afterwards, note that the same version may not necessarily be accessed the next time. A read lock is always set on the active area instance version. ABAP_HINT_END
Change Locks A change 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 method ATTACH_FOR_WRITE and an update lock is set if an area handle is bound using the method ATTACH_FOR_UPDATE. On an ABAP_ASINSTANCE , there can be a maximum of one change lock on an area instance. A change lock locks an area instance exclusively, which means that no parallel read locks are possible on this version. Parallel reads are only possible on the same area instance if area instance versioning is activated. Once a change lock has been set in an ABAP_ISESS , 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 during write access.
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 ABAP_ISESS , a maximum of one change lock can be set for an area instance using ATTACH_FOR_WRITE and ATTACH_FOR_UPDATE. These methods cannot be used to set a change lock if one already exists within the same ABAP_ISESS on any area instance version, otherwise the exception CX_SHM_CHANGE_LOCK_ACTIVE would be raised. The method MULTI_ATTACH, on the other hand, can be used to set multiple parallel change locks on multiple area instance versions.
Releasing Locks In addition to using the method DETACH , read locks are also released automatically when an ABAP_ISESS is ended. Change locks must always be released explicitly using DETACH_COMMIT or DETACH_ROLLBACK . In the following situations, there can be no change locks for an area instance version, otherwise the runtime error SYSTEM_SHM_CHANGE_LOCK_ACTIVE would occur:
Closing an ABAP_ISESS except with the statement LEAVE TRANSACTION (or the function '/n')). The statement LEAVE TRANSACTION releases all change 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 are initialized to an area handle 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, but change locks can no longer be released and the above runtime error occurs.
Latest notes: In transactional areas, note that a change lock released using the method DETACH_COMMIT still has to be released with a database commit before an ABAP_ISESS or program call (SUBMIT, CALL TRANSACTION, or LEAVE TO TRANSACTION) is closed. ABAP_HINT_END
