cancel
Showing results for 
Search instead for 
Did you mean: 

SAP Locking Vs Database Locking

former_member556881
Participant
0 Kudos

Hi Frens,

Why do i need SAP Locking on the top of Database Locking?

Plz let me know , thanks in advance..

Regards,

Dinakar

Accepted Solutions (1)

Accepted Solutions (1)

lbreddemann
Active Contributor
0 Kudos

Hi Dinakar,

Database Locking is working within database transactions.

SAP transactions are made of one or more database transactions. This is due to what is called "workprocess multiplexing".

Let's have an example for this to make it clear:

The classic SAP transaction consists of several screens where user interaction takes place.

For our example let's assume we've SCREEN 1 to select the data we want to work on and we've SCREEN 2 where we change data.

When we call the transaction our session is assigned to one of the available work processes (WP1).

This workprocess now processes the ABAP and generates the screen layout which is then send to the frontend.

The frontend now displays the screen layout and waits for user input. Meanwhile the workprocess is already busy again for some other session.

Once we've entered which data we want to edit, our sessions gets again assigned to one available workprocess (this may be a completely different one than before, WP2) and the information is sent to this workprocess. Now a SAP lock is aquired for our data and our SAP session - not for the workprocess and not for the database session.

When we get back the edit screen in the frontend, the workprocess is not bound to our session anymore - the frontend is waiting for our input.

If SAP would rely on database locking the workprocess would have to hold the database lock and it would also need to be bound for our session exclusively. That would mean: while we're actually edit the data in the frontend, the workprocess is idle.

Therefore it makes sense to have an extra locking mechanism that takes care of this.

By decoupling the lock management from workprocesses we gained more scalability and the opportunity to have the workprocesses less idle while frontend work is done.

BTW: the "quality" of the locking on database level is not worse or better between the supported database systems. All of them do support different locking modes for data - lock out for "isolation levels" in the transaction handling sections of the database documentation.

Hope that gives you an idea why a toplevel locking is necessary for SAP.

For a more detailed description you may want to read further here:

<a href="http://help.sap.com/saphelp_nw70/helpdata/en/41/7af4c8a79e11d1950f0000e82de14a/frameset.htm">The SAP Lock Concept</a>

Best regards,

Lars

Answers (2)

Answers (2)

former_member556881
Participant
0 Kudos

Hi Lars,

Thank you for your time n reply, that's pretty good justification..........

Regards,

Dinakar.M

Former Member
0 Kudos

Thank u soo much lars..even I too need the same

former_member204746
Active Contributor
0 Kudos

SAP is compatible with about a dozen databases.

SAP DOES NOT rely on database locking mechanism because each database uses different locking mechanism.

So, SAP decided to use their own locking mechanism with ENQUEUE.