TAW12 SHARED OBJECTS

SHARED OBJECT: USES

User-defined shared memory areas can be created to store data. These areas can be used to save catalog information and shopping cart-related data.

MEMORY MODULE OF AN APPLICATION SERVER

With the introduction of shared objects, the concept of the shared memory is extended to the shared objects memory. Initially, data exchange between the program and the memory in a user session used import and export parameters. This new concept makes use of instances to store and retrieve information in shared memory areas.

ACCESSING SHARED OBJECTS

One of the key characteristics of shared objects memory is faster data retrieval. As shown in the slide, two different user sessions are trying to access the same memory area instance in shared objects memory.

PROPERTIES FOR SHARED OBJECTS

Shared objects have various advantages:

  Cross program buffering of data is possible.

  Simultaneous read accesses are supported.

  Lock mechanism is used for access control.

  Data is saved in the form of attributes of objects.

  Memory bottlenecks which cause runtime errors must be resolved.

AREAS AND AREA INSTANCES

In shared memory, an area is created using transaction SHMA. It acts as a template for instances that can be stored in that area. As shown in this slide, an area can have many area instances, with each instance further divided into several area instance versions. Each area instance version is identified by a unique version ID.

CREATING AN AREA

In ABAP, shared memory area can be created using transaction SHMA. When you specify an area name, a global final area class with the same name is created. The generated area class is a subclass of the area root class.

EXAMPLE APPLICATION

Let us create a flight catalog class for flight bookings. For this, we need an area handle instance, area root class, and a catalog class.

ACCESSING AREAS

In this slide, two different applications running in different user sessions are trying to access objects in the same area. The prerequisites needed for the example application area are

  an area,

  a program which creates an area instance, and

  a program to read data from the area.


AREA MANAGEMENT

To create an area, use the transaction code SHMA and specify the area name, as shown. The area name must start with Y or Z. The SHMA transaction is used to create and manage areas.

MAINTAINING AREAS

When you are in the process of creating an area or managing an existing area, the screen shown here appears. Area root class must be assigned to each area. An area instance version must contain at least one instance of the area root class as its root object.

BEFORE CREATING AN AREA INSTANCE

When you create an area using the transaction SHMA, a global final class with the same name is automatically created. In order to create a new area or access an existing area, a reference variable that is typed with the generated area class is required. The area can be accessed using this reference as a handle.


CREATING AN AREA INSTANCE

When an area class is instantiated, an instance is created in the memory. Here, go_handle acts as a handle for the area instance.

GENERATING OBJECTS IN SHARED MEMORY

As shown here, the AREA HANDLE addition is used in the CREATE OBJECT statement to create an object in the shared objects memory. Henceforth, the area handle is used to perform any operations on the area.

GENERATING OBJECTS IN SHARED MEMORY II

Here, the objects, go_root and go_catalog, are instantiated from the main program. The root object, go_cat, can also be instantiated here.


SETTING THE ROOT OBJECT

You can make use of the set_root method to assign the root object to the root of the area handle. After this assignment, any program can access the objects contained in this area by passing a reference to the area instance.

RELEASING THE WRITE LOCK

Objects contained in an area can be read only when the write lock associated with the object instance is released. The method, detach_commit, is used to release the write lock.


ACCESSING AN EXISTING OBJECT IN SHARED MEMORY

The read program requires a handle of the area instance to access an already existing area application. The method, attach_for_read, can be used to do so.

CANCELLING THE READ LOCK

Once the read operation is complete, the read lock associated with the area instance is released using the detach method. However, the read lock is automatically released once the internal session is closed.

SETTING A READ LOCK ON THE ACTIVE VERSION

Once an area instance is created, the commit method is called internally. This activates the area instance version and the read lock is automatically applied.

VERSION BEING SET UP

A new version of an area instance can be added if the Number of Versions attribute is set for the area. When the change lock is set for an area instance, a “version being set up” gets created and can coexist along with all the previously existing ones.

WRITE COMPLETE - PREVIOUS VERSION IS OUTDATED

If the set-up of the new version is final when the area instance is in the read lock mode, then the newly added version becomes the active version. The earlier existing version automatically becomes outdated.


NEW READ LOCKS FOR THE NEW ACTIVE VERSION

While the read locks for the outdated version still exist, the read locks for the active version are set. The results of read operation may be ambiguous at this time.

NO MORE READ BLOCKS FOR OUTDATED VERSION: VERSION EXPIRED

Once the read lock is set up on an active version, the read lock associated with the outdated version is removed and the version expires.

NEW READ LOCKS FOR ACTIVE VERSION

Any number of read locks can be set for the active version. However, an area instance can have only one active version at a time.