SAP SHM AREA FIXED PROPERTIES



Get Example source ABAP code based on a different SAP table
  



ABAP_SHM - Fixed Area Properties
Like basic properties, fixed properties of an area can be only be changed by developers. When the fixed properties of an area are changed at runtime, all area instances of the area are set to the state expired and the area class must be regenerated in most cases.
Area binding This property determines the visibility and lifetime of the area instance version of the area by specifying a context. The possible contexts are as follows:
Application server
Area instance versions exist until the ABAP_ASINSTANCE is shut down. In areas with the area binding Application Server, the methods FREE_AREA, FREE_INSTANCE, INVALIDATE_AREA , and INVALIDATE_INSTANCE of the area class have a parameter called AFFECT_SERVER that can be used to control cross-server invalidations.
User session
Area instances exist until the last ABAP session of the current user session ends. In area bindings, every user logon to an AS ABAP counts individually. This also applies in particular when users log on via external interfaces such as RFC or ICF.
Top level transaction
The top level transaction is the first program in a call sequence. These area instances exist for as long as the ABAP memory assigned to a call sequence is loaded, in other words for as long as the ABAP_ISESS of the top level transaction is loaded. In area instances, the SAP Easy Access program also functions as a top level transaction.
Area instance versioning This property determines whether there can be only one or more area instance versions of an area instance. Without versioning, there is only one version and the area instance is equivalent to this area instance version. If versioning is used, there can be multiple versions in different states and an area instance is the set of all area instance versions with the same area instance name. Without versioning, multiple readers from different ABAP_ISESSNS can access an area instance after its construction but writes are only possible if no read locks are in place. If versioning is used, a change lock can be set on an area instance that still has read locks. The maximum number of versions of an area instance can be specified in the runtime-dependent area properties.