Pessimistic Locking mechanism in SAP Gateway.

[velsankar_sundar]

Hi All,

           I am new to SAP Gateway. I know there are two types of locking mechanism ( optimistic and pessimistic) . Optimistic we do by etag and if-match.

Is there any idea of how to do by pessimistic approach.

For example we are reading a contract and then updating it. So, in get_entity we have to put the lock while reading and we have to unlock while updating. But how does it works. Whether the lock automatically get released after the get_entity method.

Kindly guide me in proceeding further.

[former_member184867 · Accepted solution]

Hi Sundar,

Here is my opinion :

          Gateway is Completely Stateless till the current version which is SP8. So Pessimistic Locking would not be available out of the box by Gateway. You need to implement your custom logic to achieve this behaviour. However simulating a Pessimistic Lock in a complete stateless architecture will lead to many complexities which often might lead to inconsistency in the Application.  As mentioned by Krishna, you can store lock information in some table in backend , but it might get messy very easily. I would not recommend to do so. However if you are really keen to do Pessimistic Locking kind of mechanism, what about the following approach -----

1. In the OData service, let us have an extra Entity  called LOCK which has properties such as USER, RESOURCE_ID(such as contract ID),DATE,TIME. USER and RESOURCE_ID is the key in this entity. This data is stored in a table in database.

2. When a particular USER  opens the CONTRACT screen in EDIT mode, the UI fires a POST(Create) call for Entity LOCK with the USER and RESOURCE_ID(contract ID in this case). In the backend database table if no entry exists with that USER ID and RESOURCE_ID, then a new entry is created and the USER is allowed to EDIT the contract. If an entry already exist in table then it means some other user is already in Edit mode , and the current user is refused to access the resource in edit mode.

3. When the USER saves the CONTRACT you need to fire a DELETE request for that Particular LOCK entity. Thus is resource is dequeued.

However this is like a vanilla flow. Handling can be complicated if user closes the browser, disconnects the network connection, opens parallel session etc etc.

          Rather a clean approach would be an Optimistic lock. Fiori Applications are using this mechanism to handle concurrency control. You may refer to my reply on for a little more information on Optimistic Locking.

I agree that even though Optimistic locking works pretty well in REST based applications as it allows operations to be free from overhead of long transaction , there can be situations as mentioned below, where an Optimistic lock might not be preferred -

1. Where the chances of concurrency collision is very high (Example: Online Reservation of Tickets)

2. If modifying the resource by the user requires a lot of typing (However JS libraries such as Garlic.js, sisyphus.js or HTML5 Local storage can help us here )

Now it is upto you to decide upon the approach ..

[kammaje_cis]

oData/NW Gateway does not support Pessimistic locking. This is partially due to 'http is stateless'.

I understand that your client may not like Optimistic locking and you might have to use your consulting skills to convince them.

You can try making specific oData calls state full, by storing status(exampled: locks) in backend, but it can turn messy soon.