The name of an area. This is also the name of the generated global
area class and is therefore unique across the system.
We recommend following the naming conventions for global classes in the current system and using 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 that the other objects are referenced from. The ROOT attribute 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 by its
name. In client-specific
areas, the area class methods refer to accessing an area instance on the current client. In client-specific
areas, these methods have the additional input parameter CLIENT, which enables explicit access to other
clients. Note the restriction that it is not possible to set locks by specifying the client explicitly
if automatic area building is possible. For 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 a change lock is removed using method DETACH_COMMIT of the
area handle. 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 in the structure. No new change locks can be set on the area instance, and read locks access the previous active version. In non-transactional areas, the
state of the area instance version is set to active as soon as method DETACH_COMMIT is executed.
With transactional areas, methods FREE_AREA, FREE_INSTANCE, INVALIDATE_AREA and INVALIDATE_INSTANCE of the
area class have a parameter called AFFECT_SERVER that can be used to control the cross-server invalidation.
Transactional areas enable data or objects in the area instance versions to join such areas to database
contents. 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. During updating for example, changes to the shared objects should only be made while the corresponding update functional module is being executed.