BUFFERING IN SAP ABAP

Buffer Components:
Definition
An SAP buffer consists of the following parts:

Mode table

The mode table resides in shared memory and tells you which pool contains which shared memory areas. The mode table is part of the common information on the shared memory areas that are accessed by the work processes.

For example, SAP Key 1 with Mode = 0, instructs the OS kernel to extract this buffer from the default pool and to allocate a unique shared memory segment. SAP Key 10 with Mode = pool size instructs the OS kernel to store the buffer specifically in pool 10. SAP Key 11 with Mode = -10 means that the buffer is located in pool 10.
SAP Global Management Table A shared memory area that is allocated by the dispatcher during system startup.

When semaphore protection is on, the SAP Global Management Table is addressed exclusively by SAP Shared Memory Management. This is a central agent that is found in each work process and that sets up a shared memory area for the local application server or instance. The SAP Shared Memory Management issues a call to the operating system (OS) when it creates a shared memory area.


As a result, the SAP key is assigned to an OS key. The OS returns a unique identifier (handle) for the shared memory area, with which the SAP Shared Memory Management addresses the shared memory area that was created by the OS. All work processes in the SAP System can access the SAP Global Management Table. The handle can be accessed by all work processes.


Address Table Every work process contains this table. Assigns virtual addresses to the physical addresses of the shared memory areas.


Shared Memory Objects These include the buffers, for example.
Header Contains information on the shared memory area (also called memory segment). If a write error occurs outside the segment area, then the uniformity of the header is destroyed. The control function of the SAP Management of Shared Memory checks the consistency of the headers.


ID Identifies the memory area. The ID is assigned when a SAP Shared Memory Management user requests the memory area.
Storage Class The memory class. Examples of memory classes: permanent (local), shared, roll, paging and short.
Subdivision A mark for the requested area that can be referred to later when you release the memory area.



Definition


The name table (nametab) contains the table and field definitions that are activated in the SAP System. An entry is made in the Repository buffer when a mass activator or a user (using the ABAP Dictionary, Transaction SE11) requests to activate a table. The corresponding name table is then generated from the information that is managed in the Repository.


The Repository buffer is mainly known as the nametab buffer (NTAB), but it is also known as the ABAP Dictionary buffer.


The description of a table in the Repository is distributed among several tables (for field definition, data element definition and domain definition). This information is summarized in the name table. The name table is saved in the following database tables:


• DDNTT (table definitions)
• DDNTF (field descriptions)


The Repository buffer consists of four buffers in shared memory, one for each of the following:


Table definitions TTAB buffer Table DDNTT
Field descriptions FTAB buffer Table DDNTF
Initial record layouts IREC buffer Contains the record layout initialized

depending on the field type


Short Nametab SNTAB buffer A short summary of TTAB and FTAB buffers
The Short nametab and Initial record layouts are not saved in the database. Instead, they are derived from the contents of tables DDNTT and DDNTF.


When access to a table is requested, the database access agent embedded in each work process first reads the Short nametab buffer for information about the table. If the information is insufficient (for example, the SELECT statement uses a non-primary key) it accesses the Table definitions buffer and then the Field descriptions buffer. By reading the Repository buffers, the database access agent knows whether the table is buffered or not. Using this information, it accesses the table buffers (partial buffer or generic buffer) or the database.


The IREC buffer is read:


• When a REFRESH command is executed in an ABAP program
• At an INSERT command, when a record is created in the buffers before the data is inserted and the fields are initialized with the values found in IREC buffer
You can set the buffers mentioned above by editing the parameters in the instance profile




There are two kinds of table buffers:
• Partial table buffers
• Generic table buffers


Use


The table below displays these table buffers and their functions.



Whether a table is partially buffered, generically buffered, or fully buffered depends on its attribute settings. You can change the buffer attributes of a table using Transaction SE13.

Definition

The following table displays the program buffer and its functions.
Buffer Also known as Function
Program buffer SAP executable buffer ABAP buffer PXA (Program Execution Area) Stores the compiled executable versions of ABAP programs (loads). The contents of this buffer are stored in tables D010L (ABAP loads), D010T (texts) and D010Y (symbol table).

The program buffer has a hash structure and supports LRU (Least Recently Used) displacement.
You can reconfigure the program buffer by adjusting its instance profile parameters.


Definition

There are two kinds of SAPgui buffers:

• Presentation buffers
• Menu buffers

The following table shows the SAPgui buffers and their functions:

Roll and Paging Buffers, Extended Memory

Definition

The roll and paging buffers are the preferred working area of the roll and paging areas for an instance (application server). The remaining area is located on disk as roll and paging files. The user context is stored in the extended memory and the roll area (when the job is "rolled out" of a work process). The paging area stores special data for the ABAP processor, while the extended memory stores a large portion of the internal tables of a program.

You set the roll and paging buffers, as well as the extended memory using the parameters in the instance profile

SAP Calendar Buffer

Definition

The SAP calendar buffer stores all defined factory and public holiday calendars.
Calendars are stored in the database tables TFACS and THOCS.
The buffer has a directory structure. This means that if the shared memory is configured too small, only the required data is loaded; there is no LRU displacement of the contents of the buffer.

You can change the calendar buffer by editing the parameter in the instance profile

SAP Cursor Cache

Definition

The SAP cursor cache helps to improve system performance by reducing the number of parsing of SQL statements; it is database-dependent. The SAP cursor cache is only slightly different for Oracle, Informix and SAP DB. It is totally different for AS/400 and MS SQL Server.
There are two types of cursor caches:
• Statement ID cache
• Statement cache

Changing the SAP cursor cache parameter value in the default profile will affect other areas as well. You are therefore advised not to tune it without the recommendation of a qualified SAP expert.

Statement IDs and the Statement Analyzer
The source of each SQL statement in the SAP System (ABAP, DYNP, the C modules of the database interface) assigns an ID to its Open SQL / Native SQL etc. statement. The statement ID includes:

• Module name (report name)
• Statement number (line number)
• Timestamp (time of ABAP generation)

The statement ID provides an easy way to recognize statements. There may be different statement IDs for one statement (for example, different ABAP programs doing the same SELECT ). The Statement Analyzer eliminates such duplicities. When it receives an SQL statement (in control block form), this database interface module checks if the statement is simple (for example, SELECT * FROM T100 WHERE... =... AND... =... ), or complex (for example, SELECT * FROM T100 WHERE... <... AND... >... ). If the statement ID is simple, the Statement Analyzer assigns a ‘normalized’ statement ID.
The analyzer is called by the RSQL or Open SQL interface. If it is able to assign a normalized ID, the original ID (if existing) is replaced.

SAP LOCK CONCEPT:

If several users are competing to access the same resource or resources, you need to find a way of synchronizing the access in order to protect the consistency of your data.

Example: In a flight booking system, you would need to check whether seats were still free before making a reservation. You also need a guarantee that critical data (the number of free seats in this case) cannot be changed while you are working with the program.

Locks are a way of coordinating competing accesses to a resource. Each user requests a lock before accessing critical data.

It is important to release the lock as soon as possible, so as not to hinder other users unnecessarily.

Whenever you make direct changes to data on the database in a transaction, the database system sets corresponding locks.

The database management system (DBMS) physically locks the table entries that you want to change (INSERT; UPDATE, MODIFY), and those that you read from the database and intend to change (SELECT SINGLE FROM FOR UPDATE). Other users who want to access the locked record or records must wait until the physical lock has been released. In such a case, the ABAP program waits until the lock has been released again.

At the end of the database transaction, the database releases all of the locks that it has set during the transaction.

In the R/3 System, this means that each database lock is released when a new screen is displayed, since a change of screen triggers an implicit database commits.

To keep a lock set through a series of screens (from the dialog program to the update program), the R/3 System has a global lock table at the application server level, which you can use to set logical locks for table entries.

One application server contains this lock table and a special enqueue work process, which administers all requests for logical locks in the R/3 System. All logical lock requests of the R/3 System run using this work process.

You can also use logical locks to "lock" table entries that do not yet exist on the database (inserting new lines). You cannot do this with physical database locks.

For further information, see the ABAP Editor Keyword documentation for the term Locking.

Logical locks are generated when an entry is written in the lock table. You use function modules to do this.

You can only set a lock if the relevant table entry is not already locked.

The SAP transaction receives information on the success of a lock request from a return code sent via the EXCEPTION interface of the function module. In other words, the control is returned to the program using the function module. The ABAP program does not need to wait.

The SAP transaction can react appropriately by analyzing the return code.

Another user cannot gain access to work with the same table entries that are already locked.

Depending on the bundling technique in use for database updates), the program must delete the lock entries it generated using a lock module, or have them deleted indirectly (see unit Organizing Database Updates).

If the user terminates the program that generated the lock entries (usually a dialog program), the locks are released automatically (implicitly). You can do this by entering /n in the command field, or with the statements LEAVE PROGRAM, LEAVE TO TRANSACTION, and 'A' or 'X' Messages.

When you call an ENQUEUE function module, the dialog program tries to generate a lock entry.

The export parameters identify the table entry (or entries) that you want to lock.
The program that generates the locks (usually dialog program) analyzes the return code for lock requests and reacts accordingly.

If the lock could not be set; you should normally output an error message.

At the end of the dialog program, you can use the corresponding DEQUEUE function module to delete the entries from the lock table.

DEQUEUE function modules have no exceptions. If you try to release an entry that is not locked, this has no effect.

If you want to release all of the locks that you have set, at the end of your dialog program, you can use the function module DEQUEUE_ALL.

The lock table contains the lock arguments for each table (for lock arguments, see the following slide).

To display the lock table, use transaction SM12.

The entries in the lock table are standard. Locks are always set using the values of the key fields in a table. These form the lock argument.

You pass the values for the lock argument to the lock modules via their interface (function module IMPORT parameters).

If you fail to set any of these parameters, the system interprets it generically, that is, the lock is set for all table lines that meet the criteria specified in the other parameters. The client parameter is an exception to this rule, where the default client SY-MANDT applies.

Lock entries must be assigned to a lock mode.

There are three different lock modes:

Mode 'E' for write locks: This is set if you want to write data to the database (change, create, or delete).


Mode 'S' for read locks: This is set if you want to ensure that the data, which you are reading from the database in your program, is not changed by other users while the program is running. You do not want to change the data itself in your program.

Mode 'X' for write locks: Like mode 'E', mode 'X' is used for writing data to the database. The technical difference between mode 'X' and mode 'E' is that locks of mode 'X' are not accumulated while a program is being executed. (For further details, see the following pages).

If someone tries to lock the same data record again with a second program (different user), the various lock modes take effect as follows:

Write locks ('E' or 'X') mean that any lock attempts from other users are refused, irrespective of the mode in which the lock is attempted.

If a data record is locked in mode 'S' (shared), further locks in mode 'S' may be set by other users.

Lock attempts in other lock modes ('E' or 'X') are refused.

If you want to try to lock a data record more than once while a program is running (for example using a function module that you call up, which sets locks itself), the lock system reacts in the following way:

Mode 'E' write locks are not refused. Instead, a cumulative counter is incremented. The same applies to read locks (mode 'S').

If a data record is locked in mode 'E', a lock request generates a second lock, which is marked as a read lock.

If a data record is locked in mode 'S' and no further read locks are set by other users, a lock attempt in mode 'E' is possible. This generates a second entry in the lock table (for mode 'E').

If a data record is locked in mode 'X', all further lock requests are refused.

If you want to ensure that you are reading up-to-date data in your program (with the intention of changing and returning this to the database), you should use the following procedure for lock requests and database accesses in your program:

First, lock the data that you want to edit.

Then read the current data from the database.

In the next step, process (change) the data in your program and write this to the database.

In the final step, release the locks that you set at the beginning.

This procedure ensures that your changes run fully with lock protection and that you only read data that has been changed consistently by other programs (provided that these also use the SAP lock concept and follow the procedure described here).

Lock modules are created for lock objects and not tables.

Lock objects are maintained in the dictionary. Customer lock objects must begin with "EY" or "EZ".

A lock object is a logical object composed of a list of tables that are linked by foreign key Relationships. Lock modules are generated for these objects and enable common lock entries to be set for all tables contained in the lock object. This allows combinations of table entries to be locked.

The list of tables for a lock object consists of a primary table. Further table entries are referred to as secondary tables. Only tables with foreign key relationships to the primary table can be used as secondary tables.

With lock objects, you can assign different names for the parameters that describe the fields of the lock arguments for the lock modules. The names of the table fields (key fields of the tables) are proposed by the system.

You can specify the lock mode (a write lock 'E' or 'X' or a read lock 'S') for each table. These function as default values for the lock modules.

After you have assigned tables and default lock modes, lock objects must be generated.

When you activate a lock object, the system generates an ENQUEUE and a DEQUEUE function module.

These have the names ENQUEUE_ and DEQUEUE_ respectively.

If you want to ensure that you are reading current data in your program (with the intention of changing and returning this to the database), you should use the following procedure in your program for lock requests and database accesses:

1. Lock the data that you want to edit.
2. Read the current data from the database.
3. Process (change) the data in your program and write this to the database.
4. Release the locks that you set at the beginning.

This procedure ensures that your changes run fully with lock protection and that you only read data, which has been changed consistently by other programs (with the restriction that these are also using the SAP lock concept and following the procedure described).

If you change the order of the four steps to Read -> Lock -> Change -> Unlock, you run the risk that the data read by your program will not be up to date. Your program can read data before another user's program writes changes to the database. This means that a user of your program will make decisions for entries that are not based on up-to-date data from the database. For this reason, you should always follow the recommended procedure.

Requesting a lock from a program is a communication step with lock administration. The Communication step requires a certain time interval. If your program sets locks for several objects, this interval occurs more than once.

By using so-called local lock containers, you can reduce these communication intervals with lock administration. To do so, collect the required lock requests of your program and send them together to lock administration.

The locks (delayed execution) can be collected when the lock modules are called. For this purpose, qualify the IMPORT parameter_collect with 'X'. The data transferred via the lock module interface is then registered in a list (lock container) as a lock request that needs to be executed.

The lock container can be terminated using the FLUSH_ENQUEUE function module and sent to lock administration.

When the lock orders of a lock container can be executed, the lock container is deleted.

If one of the locks in a container cannot be set, the function module FLUSH_ENQUEUE triggers the exception FOREIGN_LOCK. In this case, none of the registered lock requests is executed. The registered locks remain in the lock container.

You can delete the contents of an existing lock container with the function module
RESET_ENQUEUE.

The specified function modules have release status internally-released.

LOCKS IN SAP ABAP

Using the SAP Locking Facility

Definition of an SAP lock

The description of an SAP lock to a table is made via the lock condition
and the lock mode.

The lock condition is a logical condition for the lines of the table to
be locked. It describes the area of the table which the lock is to
protect from competitive access. To avoid the administration of the lock
becoming complicated, the lock condition can not be formulated as freely
as the WHERE clauses: only fully qualified key fields related by AND
may appear in the condition.

Via the lock mode you define which operations on the table are to be
protected by the lock. The lock modes available are:


o Read lock (shared lock)
protects read access to an object. The read lock allows other
transactions read access but not write access to the locked area of
the table.

o Write lock (exclusive lock)
protects write access to an object. The write lock allows other
transactions neither read nor write access to the locked area of the
table.

o Enhanced write lock (exclusive lock without cumulation)
works like a write lock except that the enhanced write lock also
protects from further accesses from the same transaction.

In order to be able to define SAP locks for a table, you must first
create a lock object for the table via Development->Dictionary.
If the data for an application object is distributed among several
database tables, it is often necessary to be able to lock these tables
simultaneously. It is therefore possible to include several tables in a
lock object, althought they must be related via appropriate foreign key
relationships. The tables involved in a lock object are also known as
its base tables.

Requesting an SAP lock

When a lock object obj is activated, two function modules (see CALL
FUNCTION) with the names ENQUEUE_obj and DEQUEUE_obj are generated.
These lock modules are used to explicitly request or release SAP locks
in an ABAP program. The SAP lock concept thus assumes a cooperative
behavior by all the programs involved. This means that access from
programs that do not call the specified modules are not protected.

The lock conditions and lock modes for the requested locks are defined
by the IMPORT parameters of the lock modules.

The lock conditions are defined by the lock parameters of the lock
object. If the lock object has only one base table, each primary key
field of the table corresponds to exactly one lock parameter. Apart from
this, a lock parameter corresponds to a group of primary key fields that
are identified by the join conditions. For each lock parameter par, the
lock modules have two IMPORT parameters with the names par and X_par.
The lock condition is defined by these parameters. If a parameter par is
not defined or if it is defined with the initial value, this means that
the corresponding key fields should be locked generically. If you really
want to lock the key field with the initial value, you must also define
the parameter X_par with the value 'X'.

To define the lock modes, the lock modules have an IMPORT parameter
MODE_tab for each base table tab, with which the lock mode for this
table can be defined. A default value must already be set for this
parameter in the definition of the lock object.

You cannot set an SAP lock by finding all the lines of the table which
satisfy the lock condition and marking them as locked. Rather, the lock
condition and lock mode for a table are entered in a special lock table.

Collision of SAP locks

Before a requested SAP lock is entered in the lock table, a check is
made on whether it collides with a lock already entered in the lock
table. Two locks on the same table collide if their lock conditions
overlap and their lock modes are incompatible.

The overlapping of two lock conditions on one table is a purely logical
attribute. It occurs if a row of the table which meets both conditions
could exist. It is therefore irrelevant for the overlap whether or not
such a row really exists in the table.

The following rules apply for the compatability of locks: An enhanced
write lock is incompatible with all other locks, a write lock is
incompatible with all locks requested by other transactions, and a read
lock is compatible with all other read locks.

If locks are requested with the help of a lock object that has several
base tables, all locks requested are regarded as colliding as soon as a
collision is recognized for just one of the base tables involved.

Behaviour in a collision

An SAP lock that collides with an existing lock cannot be granted and is
therefore not entered in the lock table.

With the help of the IMPORT parameter _WAIT, you can determine how the
ENQUEUE module should behave if the lock it requests collides with an
existing lock. If this parameter has the value ' ', the exception
FOREIGN_LOCK is triggered. The system field SY-MSGV1 is supplied with
the user set by the the colliding lock.
If the parameter has the value 'X', the lock request is repeated at set
intervals until either the lock can be granted or an internal system
time limit is exceeded. In the second case the exception FOREIGN_LOCK is
also triggered.

Duration of an SAP lock

At the end of a transaction, this automatically releases all the SAP
locks it holds. Note, however, that if an update routine is called by
the transaction, locks can be transferred from the ordering transaction
to the update routine. In the same way, these locks are automatically
released at the end of the update routine. Via the IMPORT parameter _SCOPE of the ENQUEUE module, you can determine
whether a lock should be transferred to the update routine if one is
called.
If _SCOPE has the value '1', the lock remains with the the ordering
transaction. If _SCOPE has the value '2', the lock can pass to the
update routine. Finally, if the parameter has the value '3', two locks
of the same kind will be generated, one of which passes to an update
routine when one is called.

By calling the DEQUEUE module, a transaction can explicitly release a
lock which it holds. The lock parameter and lock mode must be supplied
with the same value as for calling the ENQUEUE module. If the parameter
_SCOPE has the value '1', only one lock is released which cannot pass to
an update routine. If the parameter has the value '2', only one lock is
released which can pass to the update program. Finally, if the parameter
has the value '3', both locks can be released. Note however that a
transaction can release neither a lock which has already been
transferred to the update program, nor a lock which is held by another
transaction.
Via the IMPORT parameter _SYNCHRON you can control whether the release
of the lock should be synchronous or asynchronous. If this parameter has
the value 'X', the module waits until the lock has really been removed
from the lock table. If the parameter has the value ' ', a requst for
deletion of the lock from the lock table is sent to the application server which manages the lock table, and then the execution of the
program is immediately continued.

Monitoring of SAP locks

The transaction Display and delete locks monitors the SAP locks.

LOCK PARAMETERS

Definition of the lock parameters of a lock object:

The lock parameters of a lock object are used when the relevant lock
modules are called to allocate the values to the lock arguments of the
lock object.

For each parameter field of the lock object (at most) one lock parameter
can be defined.
The name of the lock parameter generally corresponds to the name of the
relevant parameter field. The name can however be freely chosen as long
as it adheres to the name conventions for lock parameters.

For each parameter of the lock objects the relevant lock modules
receive IMPORT parameters and X_. The parameter
possesses the relevant parameter field as reference field. If the IMPORT
parameter is filled with a value in a call, all the lock fields
equivalent to the parameter field in the corresponding lock arguments
are filled with that value. If the parameter remains initial, generic
locking takes place on these lock fields. If however the flag X_ is
set, initial also means that the corresponding lock field should
be locked at initial value.

NAMING CONVENTIONS OF LOCK OBJECTS

When naming the lock parameters of a lock object, the following
conventions apply:

1. No lock parameter may appear twice in a lock object.

2. Each lock parameter name must adhere to the name conventions for
table fields.

3. No lock parameter name may begin with the prefix 'X_'.

4. No lock parameter name may begin with the prefix 'MODE_'.

5. No lock parameter name may correspond to the name of a Basis table.

6. The names 'DDENQ_LIKE' and 'DD26E' are not allowed for lock
parameters.

LOCK FIELDS

Definition of the lock fields of a lock object:

The lock fields of a lock object are the key fields of the base tables
of the lock object for which a lock mode is defined.
The only exception to this rule is when the lock object only has one
base table and this base table is a structure without key fields. In
this case the lock fields of lock object are precisely those parameter
fields of the lock object for which a lock parameter is defined. (Here
too a lock mode must be defined for this base table.)

The lock argument for a table is now constructed from the lock fields
within this table. By virtue of the join conditions which were used to
construct the lock object, each lock field is equivalent to one
parameter field. If a lock parameter is defined for this parameter
field, the content of the lock field in the lock argument is controlled
via this lock parameter. Otherwise only generic locking is possible for
this lock field.

LOCK MODES

Definition of the lock modes of a lock object:
In the definition of a lock object one of the three lock modes
'S'(shared lock), 'E'(exclusive lock) or 'X'(exclusive lock without
accumulation) can be specified for each Basis table.

For each Basis table , for which a lock mode was specified, the
lock modules belonging to the lock object receive an IMPORT parameter
MODE_. This has the specified value as default. In a call this can
be changed to one of the other two values. This value is then entered in
the lock granule for the table. Basis tables for which no lock mode is
defined cannot be locked with the lock object.

LOCK GRANULE

Definition of the lock granule of a lock object:

For each base table of a lock object for which a lock mode is defined, a
lock granule is formed which consists of the name of the table, the
current lock mode and the lock argument for this base table. These lock
granules are the information which is transmitted to the lock server
when a lock module for a lock object is called.


DATABASE LOCKING

Database Locking

Any database permitting simultaneous access by several users requires a
locking mechanism to manage and synchronize access. The tasks of this
mechanism are to:

- protect data objects which a transaction is currently changing
or reading from being changed by other transactions at the same
time.

- protect a transaction against reading data objects which have
not yet been fully written back by another transaction.

How is locking achieved?

Database systems do not usually provide commands for explicitly setting
or releasing locks. Therefore, prior to executing the database
operation, database locks are set implicitly when one of the Open SQL
statements SELECT SINGLE FOR UPDATE, INSERT, UPDATE, MODIFY, DELETE is
called (or when the corresponding Native SQL statement is called).

What is locked?

Database systems set physical locks on all lines affected by a database
call. In the case of SELECT, these are the selected entries. In the case
of UPDATE, DELETE, INSERT and MODIFY, they are the entries to be
changed, deleted, etc.


It is not always the table line which is locked. Tables, data pages and
index pages can also be locked. The units to be locked depend on the
database system you are using and the access being performed.

Lock mode

In principle, one type of lock is enough to control conflicting data
accesses. However, to achieve a greater degree of parallel running among
transactions, database systems use several types of locks. These can
vary from system to system, but the following two are sufficient to gain
an understanding of how locking works:

o Read lock (shared lock)

Read locks permit the setting of further read locks, but prevent
other transactions from setting write locks for the objects in
question.

o Write lock (exclusive lock)

Write locks do not allow other transactions to set any locks for the
objects in question.

How are locks set?

You set write locks with the Open SQL statements SELECT SINGLE FOR
UPDATE, INSERT, UPDATE, MODIFY and DELETE (or with the appropriate
Native SQL statements).

The decision as to whether the Open SQL command SELECT or the
appropriate Native SQL command sets the lock or not depends on the
isolation level of the transaction. Two possible levels are
distinguished:

o Uncommitted read (or dirty read)

A program using an "uncommitted read" to read data does not set
locks on data objects and does not obey them. For this reason,
programmers must bear in mind that their programs might read data
which has not yet been finally written to the database with a database commit and could thus still be deleted from the database by
a database rollback. "Uncommitted read" is the default setting in
the R/3 system for the isolation level.

o Committed read

A program using a "committed read" to read data obeys the locks on
data objects. This means that programmers can be sure that their
programs will read only data which has been finally written to the
database with a database commit. You can set the isolation level in
the R/3 system to "committed read" by calling the function module
DB_SET_ISOLATION_LEVEL. The next database commit or rollback will
reset the isolation level to its default setting, as will calling
the function module DB_RESET_ISOLATION_TO_DEFAULT.

Many database systems employ additional isolation levels (e.g. "cursor
stability" and "repeatable read"). These work like "committed read", but
the read lock is retained until the next data object is read or until
the database cursor is closed. Since these isolation levels are not
sufficiently standardized, they are not currently used in the R/3
System.

If a transaction cannot lock an object because it is already locked by another transaction, it waits until the other transaction has released
the lock. This can result in a deadlock. A deadlock occurs, for example,
when two transactions are waiting for a lock held by the other.


How long is a lock retained?

In database locking, all locks are released no later than the next database commit or rollback (see Logical Unit of Work (LUW)). Read locks
are usually retained for a shorter period. Sometimes, this causes
problems for transactions which cover several dialog steps:

In the above example, further dialog steps follow the selection of a
flight with free seats to enter additional data for the reservation.
Here, the adding of the flight reservation occurs in a different LUW
than the original selection of the flight. Database locking does not
prevent another transaction from booking this flight in the meantime.
This means that the scheduled booking may have to be canceled after all.

From the user's point of view, this solution is very inconvenient. To
avoid this scenario, a flight reservation system must use the SAP
locking mechanism (see SAP Locking) to lock the flight for the entire
duration of the transaction.

MESSAGES

MESSAGE Syntax Diagram

Variants:
1. MESSAGE xnnn.
2. MESSAGE ID id TYPE mtype NUMBER n.
3. MESSAGE xnnn(mid).

Effect Sends a message. Messages are stored in table T100, and can be
maintained using Transaction SE91. They are fully integrated
in the forward navigation of the ABAP Workbench.

The ABAP runtime environment handles messages according to the
message type specified in the MESSAGE statement and the
context in which the message is sent. There are six kinds of
message type:

A (Abend) Termination
E (Error) Error
I (Info) Information
S (Status) Status message
W (Warning) Warning
X (Exit) Termination with short dump
Messages are used primarily to handle user input on screens.


There is an Example program for messages that displays how
messages behave in various contexts.

Variant 1 MESSAGE xnnn.

Additions:
1. ... WITH f1 ... f4
2. ... RAISING exception
3. ... INTO f

Effect Sends the message nnn from message class i with type x. You
can specify the message class i in the MESSAGE-ID addition to
the REPORT, PROGRAM or other introductory statement.

Example
MESSAGE I001.

- If you want to use a different message class, you can
specify one in parentheses after the message number:
MESSAGE I001(SU).
- When the statement is executed, the following system
variables are set:
* SY-MSGID (Message class)
* SY-MSGTY (Message type)
* SY-MSGNO (Message number)

Note Runtime errors:

- MESSAGE_TYPE_UNKNOWN: Message type unknown
- MESSAGE_TYPE_X: Deliberate program termination with short
dump

TRANSATIONS


1.SCREEN NUMBERS

The screen number identifies a screen within a program (module pool,
report).

Screen numbers can be up to 4 characters long, all of which must be
digits. Screen numbers from 9000 are reserved for customer-specific
screens.

The use of screen numbers is namespace-dependent. For screens in
programs in the SAP namespace, numbers less than 9000 are reserved for
SAP screens, numbers between 9000 and 9500 are reserved for SAP
partners, and numbers greater than 9500 are for customers.