AS ABAP Release 758, ©Copyright 2024 SAP SE. All rights reserved.

ABAP - Keyword Documentation →  ABAP - Programming Language →  Creating Objects and Values →  Shared Objects →  Shared Objects - Areas → 

Shared Objects - 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 AS instance 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 internal session 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 internal sessions 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.