Get Example source ABAP code based on a different SAP table
ARTICLE
Shared Objects - Memory Bottlenecks The shared memory of an application server is a limited resource. The ABAP runtime environment uses it to store programs, program data, buffers etc. Explicit ABAP programming can access either data clusters in cross-transaction application buffers or shared objects in the shared objects memory. The maximum amount of shared memory that can be occupied by the different users is defined statically using profile parameters. Transaction ST02 shows the current utilization of the shared memory and the related profile parameters. If the amount of memory allocated to the shared objects memory (by the profile parameter abap/shared_objects_size_MB) is exceeded when shared objects are used, a treatable exception of class CX_SHM_OUT_OF_MEMORY is triggered. This exception can occur in different situations:
When shared objects are created or changed in the shared memory
When locks are removed with DETACH_COMMIT
When locks are created with ATTACH_FOR_WRITE , ATTACH_FOR_UPDATE, and even with ATTACH_FOR_READ (if there is no longer sufficient space for the administration information) For this reason, we recommend that you handle the exception CX_SHM_OUT_OF_MEMORY for all accesses to the shared objects memory. The easiest way to do this is when all accesses to shared objects (in an ideal situation, these only occur within one wrapper class) also take place in only one single TRY control structure, in which this exception is handled. If a change lock on the area still exists when the exception is handled (can be identified using the GET_LOCK_KIND method of the area handle), you should remove it with DETACH_ROLLBACK.
Note To handle the exception CX_SHM_OUT_OF_MEMORY, you should implement a suitable fallback strategy. For example, a strategy to create the required objects in the internal session and copy the previous content from the shared memory to these objects.
