User Guide
SAP AG November 2002
A high degree of concurrency is characterized by a state in which a maximum number of
concurrent can process a database without long waiting periods
for locks to be released.
•
transactions [Page 152]
• As far as consistency is concerned,
can arise through concurrent
access to the same database.
phenomena [Page
119]
The lower the value of the isolation level, the higher the degree of concurrency and the lower
the guaranteed consistency. This means that a compromise between concurrency and
consistency that best suits the requirements of the application at hand must always be found.
You can use the
to help define the isolation level
you require. The following isolation levels exist:
CONNECT statement [See SAP DB Library]
Isolation Level 0 [Page
117] (uncommitted)
•
Isolation Level 1 or 10 [Page
117]
•
(committed)
Isolation Level 15 [Page
11 ]8
•
• Isolation Level 2 or 20 [Page
118]
•
(serializable)
(repeatable)
Isolation Level 3 or 30 [Page
118]
Isolation Level 0
If isolation level [Page 139] 0 (uncommitted) is specified, rows can be read without
being requested, that is to say, shared locks are not implicitly requested. For
this reason, there is no guarantee that a given row will still be in the same state when it is
read again within the same as when it was accessed earlier, since it
may have been modified in the meantime by a concurrent transaction.
shared
locks [Page 114]
transaction [Page 152]
Furthermore, there is no guarantee that the state of a row that was read has already been
recorded in the database using COMMIT WORK.
When rows are inserted, updated or deleted, implicit exclusive locks [Page 115] are assigned
to the transaction for the rows concerned. These cannot be released until the end of the
transaction.
Isolation Level 1 or 10
If isolation level [Page 139] 1 or 10 (committed) is specified, a shared lock [Page 114] is
assigned to the
152 for a read row R1 of a table. When the next row R2 in
the same table is read, the lock on R1 is released and a shared lock is assigned to the
transaction for the row R2.
For data retrieval using a , the database system
ensures that, at the time each row is read, no has been assigned to
other transactions for the given row. It is impossible to predict, however, whether a QUERY
statement causes a shared lock for a row of the specified table or not and for which row this
may occur.
transaction [Page
]
QUERY statement [See SAP DB Library]
exclusive lock [Page 115]
When rows are inserted, updated or deleted, implicit exclusive locks are assigned to the
transaction for the rows concerned. These cannot be released until the end of the transaction.
User Manual: SAP DB 117










