ARTICLE
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.
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. For 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 an internal session except with the LEAVE TRANSACTION
statement (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 the case of a transactional area, 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.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved