Kontakt

Ansicht
Dokumentation

ABENMEMORY_ORGANIZATION - MEMORY ORGANIZATION

ABENMEMORY_ORGANIZATION - MEMORY ORGANIZATION

General Data in Customer Master   PERFORM Short Reference  
This documentation is copyright by SAP AG.
SAP E-Book

Sessions and Memory Areas

This section describes the sessions of an AS ABAP in which ABAP programs are executed and the associated memory areas that can be accessed by an ABAP program. For a more general and technically more detailed description, see the documentation Memory Management in SAP Help Portal.

The following figure shows the general organization of sessions for ABAP programs and their memory areas up to the internal session level:

IMAGE @@ABDOC_Memory1.gif@@508@@706@@

An AS ABAP can be distributed across multiple . If an AS ABAP is implemented using multiple , they are usually instantiated on different host computers, which do not have to have the same operating system. However, multiple of one or more AS ABAP can also be instantiated on the same host computer. communicate with the presentation layer, the database layer, and with each other using the message server. The most important components of an are its work processes, the number and type of which are determined when the AS ABAP is started. An ABAP program is executed by a suitable work process.

The transaction SM51 shows an overview of the of the current AS ABAP and on which host computers they are instantiated. The name of the current can be determined in an ABAP Program using the method GET_INSTANCE_NAME of the system class CL_ABAP_SYST. This name has the form hostname_sysid_instnr. Here, hostname is the name of the host computer of the , sysid is the name of the AS ABAP, and instnr is the instance number of the . The network name of the host computer on which the current is instantiated can be found in the system field sy-host.

Every has access to the standard database of the AS ABAP. Every has its own shared memory. The ABAP runtime framework uses the shared memory for programs, program data, and buffers (for example, during table buffering). ABAP programs can store shared objects and data clusters in the shared memory.

Note

The shared memory is frequently used and therefore may be a sparse resource, which can result in bottlenecks when explicitly storing data from ABAP programs.

Example

Gets the name of the current .

User Session

Logging on to an opens a user session. Logons take place using SAP GUI, the RFC interface, or ICF (including APC). A user session is assigned a separate memory area, the user memory, which can be used as follows in ABAP programs:

The maximum number of user sessions is determined by the profile parameter rdisp/tm_max_no. The profile parameter rdisp/rfc_max_login determines which percentage of the sessions can be opened using the RFC interface.

For more information, see User Sessions.

ABAP Session

An ABAP session is opened for each user session. Each ABAP session is assigned its own memory area ABAP memory, in which data clusters can be stored. The programs of a call sequence share access to these clusters and the data is retained for as long as the top level transaction of the call sequence remains. The SAP Easy Access program does not work as a top level transaction for the ABAP memory.

Additional ABAP sessions for a user session can be opened as follows:

  • Enter a transaction code after "/o" in the command field in the toolbar.
  • Call a dynpro during the processing of asynchronous RFC. In the RFC client, an additional ABAP session for communication with the SAP GUI is required.

A maximum of 16 ABAP sessions are possible per user session. The number of sessions that is actually possible for a system is determined by the profile parameter rdisp/max_alt_modes, whose default value is 16.

Notes

  • For logging and analysis purposes, each ABAP session has an extended passport (EPP) that contains constant values and that can be passed on to communication partners, such as other ABAP sessions or external interfaces, whereby modifiable values are set for the respective connection.

Internal Session

Each call of an ABAP program creates a new internal session, in which the called program is loaded.

An internal session contains a session memory that is divided into the areas heap and stack from the perspective of an ABAP program. The modifiable objects of the program live there. The non-modifiable data of the program is stored in the PXA. The session memory contains references to the required data in the PXA. From a technical perspective, the session memory and the global PXA are stored in the shared memory of the where they managed by the SAP Memory Management.

In an ABAP session, there can be a maximum of nine internal sessions that always belong to a call sequence. Data from the ABAP memory is always assigned to a call sequence.

On 64-bit platforms, an internal session can theoretically require up to 4 TB of memory. The practical upper limit is usually below the theoretical limit, since the actual physically installed main memory is the maximum available and divided up among all users.

Further information about the way ABAP programs are organized in an internal session can be found in Programs in the Internal Session.

Notes

  • The available session memory is defined using the profile parameters described under Session Memory. It is also possible to define a percentage of the available memory as a limit, over which a runtime warning occurs.
  • Instances of classes, except for shared objects, are located in the internal session. It is therefore not possible to store references to objects in the ABAP memory.
  • On 32-bit platforms, that are not supported any more, the theoretical upper limit for the memory that an internal session could require was 4GB.

Example

Usage of CL_SESSION_INFO.






Vendor Master (General Section)   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.

Length: 12184 Date: 20240511 Time: 050246     sap01-206 ( 169 ms )