Locking in RAP
Road Map for Learning Lock mechanism in RAP
Concurrency Control
Concurrency control prevents concurrent and interfering
database access of different users. It ensures that data can only
be changed if data consistency is assured.
1. Optimistic Concurrency Control:
It allows multiple users to change records simultaneously.
Ex: E tag
2. Pessimistic Concurrency Control (Locking)
Pessimistic concurrency control prevents simultaneous
modification access to data on the database by more than one
user.
Ex: Conventional locks available in se11
Optimistic Concurrency Control (E tag):
How E Tag Works:
1. When a user accesses a business object, a batch call (read
operation) retrieves the E Tag. This is typically a timestamp
that tells you the last time the record was modified.
Ex: When the business object “3eb9b5aa-d3ff-1edf-b583-
f100044fee6b” is accessed, a batch call fetches the "last
changed at" timestamp.
2. When a user modifies the record and hits "Save," the system
checks if the e tag still matches using an If-Match condition.
If the e tag is unchanged, the system modifies e tag with
current timestamp, along with updated bo.
checks the E tag value
E tag is modified with current timestamp
3. If the e tag doesn’t match, it means another user has
modified the record in the meantime. A warning is triggered,
advising the user to refresh before proceeding.
Variants of E tag:
E Tag Master:
• An entity is an e tag master if the changes of the entity are
tracked in a field within the entity itself.
• It logs the changes of a business object and typically has the
e tag field defined in the behaviour definition (e tag Field).
• Root entities are often e tag masters as they track the
changes for all related entities.
• Syntax: e tag master Changed_on
• E Tag Dependent:
• An entity is e tag dependent if it logs its changes in another
business object's entity field.
• These entities are associated with the e tag master entity,
which is specified through the behaviour definition
(_AssocToETagMaster).
• When changes are requested for an e tag dependent entity,
the system checks the e tag value of its master entity to
ensure no conflicting changes occurred.
• Syntax: e tag dependent by _Assoc
Total ETag
• In a Total e tag scenario, when draft instances are updated,
the system ensures that only the latest version of the draft
instance can be modified. This prevents the issue where
multiple users might try to modify different versions of the
draft instance concurrently.
• It’s recommended to use both Total e tag and e tag
master/dependent together in draft scenario.
• Syntax: total e tag TotalEtagField
E tag definition
• last_changed_at will be used for generating the e tag value,
auto populated using
@Semantics.systemDateTime.localInstanceLastChangedAt
annotation
• In Bdef interface, declare e tag master with changed_on field
and e tag dependent with association, note: you can also
declare child entity as e tag master, but it will not be locked
based on root node.
• In Bdef projection, declare “use etag” to enable e tag.
E tag implementation:
• Managed: Framework takes care of handling logic.
• Unmanaged: the application developer has to implement
the read operations for the ETag check.
For any queries, please feel free to reach out to me on LinkedIn:
www.linkedin.com/in/arunagirish-b-987220225
