The name of an area. This is also the name of the generated global
area class and is therefore unique across the system.
It is advisable to follow the naming conventions for global classes in the current system and use the prefix "CL_".
Area root class
The area root class is a global shared-memory-enabled class that has to be assigned to an area when it is defined. A non-empty area instance version has to contain at least one instance of the area root class as a
root object, from which the other objects are referenced. The attribute ROOT of a corresponding
area handle is generated as a reference variable with the static type of the
area root class.
Client-specific area
An area can be identified as client-specific. In this case, an
area instance of the area is identified by a
client identifier
and not just by its name. In client-specific areas, the area class methods always make reference to
the current client when accessing an area instance. Also in client-specific areas, these methods have
the additional input parameter CLIENT, which enables explicit access to other clients. If automatic
area building is possible, it is not possible to set locks by specifying the client explicitly . In
methods where this makes sense, the value of constant CL_SHM_AREA=>ALL_CLIENTS can be passed to CLIENT
to execute it on all clients. In the standard setting, the runtime-dependent area properties are client-specific. There is no check to see whether a specified client actually exists in the system.
An
area instance version of a transactional area is not active immediately after the removal of a change lock using the method DETACH_COMMIT of the
area handle and it becomes active after the next
database commit instead.
Between the time when the lock is removed and the database commit, the area instance version appears
as specified in the layout. No new change locks can be set on the area instance and any shared locks access the previous active version. In non-transactional areas, the
state of the area instance version is set to active as soon as the method DETACH_COMMIT is executed.
Transactional areas enable data or objects in the area instance versions to join areas like this with
database content. To ensure that the reference between database content and shared objects is not damaged,
changes to the shared objects should be made only in contexts in which the database changes were also
made in the current application. In updates, for example, any changes to the shared objects should only be made while the corresponding update functional module is being executed.