Shared Objects - Implementation 

Shared Objects

Shared Objects are objects in the shared memory. Instances of classes and anonymous data objects can be stored. Named data objects can be stored as attributes of classes.

Shared Memory

The shared memory is a memory area on an application server, which is accessed by all of this server’s ABAP programs. Before shared objects were implemented, ABAP programs could access this memory area using the EXPORTand IMPORT statements exclusively with the SHARED BUFFER or SHARED MEMORY additions, and instances of classes or anonymous data objects existed exclusively in the internal session of an ABAP program.

With the implementation of shared objects with Release 6.40, the shared memory was enhanced with the shared objects memory that stores shared objects. The size of the shared objects memory is determined by the abap/shared_objects_size_MB profile parameter.

Shared objects are stored in what are called shared memory areas. You create and manage areas and their properties using Transaction SHMA .

Shared Memory-enabled Classes

The prerequisite for storing an instance of a class in the shared memory is that the class of the object has to be defined with the SHARED MEMORY ENABLED addition of the CLASS statement, or that the property Shared memory-enabled has to be selected in the Class Builder. Each area is linked with what is called a global area root class, which can contain separate data and references to other instances of shared memory-enabled classes or to anonymous data objects in its own attributes.

Areas and Area Instances

An area is the template for area instances in the shared memory. Several area instances can be created from one area instance, differing from each other in name. Moreover, there can be several versions of an area instance (area instance versions), which differ from each other by a version identifier. All area instance versions of the same area instance name make up an area instance. In the simplest case (without versioning), an area instance consists of a single area instance version.

Area Classes and Area Handles

When an area is defined in Transaction SHMA, a global and final area class with the same name is generated as a subclass of CL_SHM_AREA. Class CL_SHM_AREA itself is a direct subclass of CL_ABAP_MEMORY_AREA. In an ABAP program, an area is accessed exclusively using the methods of the generated area class. There are static methods for binding an ABAP program (or its internal session) to area instances in the shared memory (attach methods). Binding creates an instance of the area class as an area handle, and creates a lock at the same time. The ABAP program can access the bound area instance version using the area handle and thus access the shared objects that are stored there. The area handle also contains the methods for deleting the connection or the lock (detach methods).

Access to Objects

The shared objects in an area instance version are addressed by references, which are obtained using the area handle. The shared objects within an area instance version can refer to each other without any restrictions. An ABAP program can contain references to shared objects provided that it is bound to an area instance version. Area instances themselves are self-contained, so that they cannot contain any references to other area instance versions or be contained in an internal session. There is one exception to this rule, provided that an area instance is bound to an internal session for writing or updating. During this time, there can be references in the area instance to objects in the internal session or to other area instances that are similarly bound.

Do not confuse area instances or area instance versions with instances of classes. In particular, an area instance is not an instance of an area class. Area instances are managed areas (the actual areas) in the shared memory in which shared objects can be stored, and which are addressed by area handles.