Shared Objects - Notes on Usage 

Usage Scenario

Access to shared objects is regulated by lock mechanisms. The individual locks are stored as administrative information with the area instances in the shared memory and are set and evaluated when they are accessed using area handles. How locks work depends on the how shared objects are used as follows:

·        Scenario 1 – Use as a shared buffer

A shared buffer is a data store that is rarely changed (once a day up to a maximum of once an hour), usually by a single user only. The amount of data can be very large. In general, many users have read access to a shared buffer at the same time. A typical use of a shared buffer is to store a catalog.

·        Scenario 2 – Use as an exclusive buffer

An exclusive buffer is a data store that is read or write accessed by one user only or – less frequently – one user with write access and another with read access. The data stored in an exclusive buffer should be available longer term, that is, longer than a program’s lifetime. A typical use of a shared buffer is to store a shopping basket that is filled initially by the shopper and then read by the salesperson later.

Other uses (general shared memory programming) are not planned. The current lock logic does not enable you to set specific locks for the following requirements:

·        Many parallel read and write accesses

·        Frequent write accesses

·        Division into changeable and non-changeable areas

Although the lock logic makes the first two points technically possible, they are not practical because most accesses would be rejected.

Wrapping

It is recommended that application programs do not access the shared objects memory directly, but that (read) accesses to the shared objects are instead wrapped in a wrapping class, whose (GET) methods are accessed by the individual programs. The area constructor class can be used as the wrapping class, for example.

Wrapping has the following advantages:

·        Central administration of an area in the shared memory

·        An application program does not need to worry about area handles and locks.

·        Central administration of locks

·        Option to implement central authorization checks

 

Restrictions

The following restrictions currently apply:

·        On 32-Bit systems, only a limited amount of memory space is available for storing shared objects, due to the restricted address space. For this reason, shared objects can only be used on 32-Bit systems under certain conditions.

·        As of Release 7.0, data objects referenced using data references can be stored directly in the shared memory. Here there is the restriction that the dynamic type may not have been created at program runtime. Furthermore, in Release 7.0, data elements and table types of the ABAP Dictionary cannot be referenced directly.

·        Memory bottlenecks in the shared objects memory cannot currently be handled and therefore cause runtime errors.

·        The memory consumption of shared objects in the shared memory cannot be monitored with the Memory Inspector.

·        There is no memory restriction for logical areas, which generally consist of several area instances. There are currently only memory restrictions for individual area instances.

·        The lifetime of area instances cannot be bound to that of user sessions, external sessions, or transactions. Area instances currently exist as long as the application server instance.