sapdev logo background
sapdev logo sapdev logo
Comments

SAP SHM AREA INSTANCE LOCKS documentation, setup help and example usage



Return to SAP documentation index


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




    SHM_AREA_INSTANCE_HANDLE
    SHM_AREA_INSTANCE_STATE




    comments powered by Disqus