Shared Objects - Locks 

A 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.

Read Locks

A read 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 read lock on an area instance within an internal session. For multiple sessions there can be several read locks on an area instance version.

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

If a read 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 read lock is always set on the active area instance version.

Change Locks

A change lock is either a write 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 change lock on an area instance. A change lock locks an area instance exclusively, that is, no parallel read locks are possible on this version. Parallel read accesses are possible on the same area instance if area instance versioning is activated.

Once a change lock has been set in a program, read and change access to the area instance version and its area instance 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, and

·        Creates a copy of the active area instance version and binds it for changing in the case of areas with versioning.

Releasing Locks

Apart from the DETACH method, read locks are released automatically when an internal session ends.

Change locks must always be released explicitly with DETACH_COMMIT or DETACH_ROLLBACK. In the following situations there cannot be any change locks on an area instance version, otherwise this would result in the SYSTEM_SHM_CHANGE_LOCK_ACTIVE runtime error and all changes would be rejected:

·        Closing an internal session other than using the LEAVE TRANSACTIONstatement (or function “/n”). With the LEAVE TRANSACTION statement, all change locks are released with the DETACH_ROLLBACK method.

·        Database commit in the case of transactional areas.

·        Program calls with SUBMIT AND RETURN, CALL TRANSACTION and CALL DIALOG 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 whilst it holds a lock, the lock remains and is not deleted. The area instance version can still be accessed, although change locks can no longer be released. This results in the runtime error above.

In the case of a transactional area, note that a change lock that is released using the DETACH_COMMIT method has to be released finally with a database commit before an internal session or a program call is closed.