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:
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.
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.
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:
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:
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
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
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)
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.
RELATED POST
ABAP PROJECT OBJECTS
ABAP REUSE COMPONENTS
No comments :
Post a Comment