ARTICLE
Areas - Basic Properties
An area has the following basic properties:
Area Name
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-Dependent Area
An area can be identified as client-dependent. In this case, an
area instance of the area is identified
by a client identifier and by its name
. With client-dependent areas, the area class methods refer to
accessing an area instance on the current client. With client-dependent
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 in order to execute it on all clients. In the
standard setting, the runtime-dependent area properties are
client-dependent. There is no check to see whether a specified client
actually exists in the system.
In tenant-isolation systems, area
instances of other clients can only be accessed in
system and
administration clients . In
application clients , it is only
possible ot access area instances of the current client. When using the
methods of the area class, parameter CLIENT cannot be passed in
the application client.
Automatic Area Building
If this property is set, a new area
instance is created automatically at the time selected in the
area build type . If this
property is to be set, an area
constructor class must be specified in the
dynamic area properties ,
and the area has to be bound to the application server.
Transactional Area
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.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved