Shared Objects - Basic Features 

Use Cases for Shared Objects

With ABAP shared objects, you can implements a buffer between multiple users or an exclusive buffer for a single user..

From a technical point of view, using shared objects memory for a shared buffer is only possible under the following conditions:

·        The buffer has a low update frequency (from once a day to once per hour)

·        It is used for large datasets

·        It is used by one writer and many parallel readers

The shared buffer is comparable to a catalog in that it is created at one position, read by many, updated at relatively large intervals, and its individual contents can be quite substantial.

Technical Implementation of Shared Objects

Technically, the shared objects memory is part of the shared memory, which can be configured using profile parameters. It consists of shared objects areas, which are created at design time with the shared objects area manager (transaction SHMA) and identified with unique names. These areas are instances of which you can, at runtime, create instances with names that are unique area-wide. You store the user data in these instances for it to be available server-wide.

You can create class instances for your user data directly in the shared memory. All objects can be accessed via the relevant root object of the instance. The shared objects area monitor (transaction SHMM) provides an overview of the areas, instances, locks, and versions of a shared objects memory.

Lock Concept

There is also a rough lock concept for shared objects areas, which is intended for the central use case of the catalog with one writer and many readers. You can only apply read, write, or update locks to complete areas. Multiple parallel read locks are possible, write locks are exclusive. Lock requests are either immediately granted or the relevant exception is raised. Only one read lock per internal session is possible for the same area instance.

Versioning

A shared objects area should, when necessary, always be available. If so desired, you should be able to ensure that a shared objects area can always be read, even while this area is being updated. In these cases, you can activate versioning for an area.

While a new version is created in the background, the readers remain connected to the old version. Once the new version is finished, it becomes the active version and the old version is then obsolete.  New readers are then connected to the new, active version. As long as any users are still reading the old version, it remains intact. Once the last reader of the obsolete version has closed his connection, this version is flagged accordingly and deleted by the garbage collector.