Pessimistic Locking between different OData-Requests with use of C_ENQUEUE?!

[haykma]

Hi Community,
we developed a fiori-app on top of a pure abap-solution for a purchase-to-pay solution from our partner to extend the reach to customers with a clear fiori-strategy.
The partner abap-solution works with SAPGui Transactions. In the past they used a separate locking table to manage the locks to their business-documents. The OData-Services of our Fiori-Solution used this table also to deal with locking.

In the newest release of our partner-solution they changed locking. The do not use a own locking-table but change to use sap locking by ENQUEUE and DEQUEUE, which means to use pessimistic locking in the transaction. The business-object is locked when starting the transaction and release at the end of the session. An administrator can use SM12 to have a look at active lockings and my manually release lockings.
Unfortunately this is now a heavy problem for our fiori-app because the OData-Requests are stateless and so locks set after reading data in the odata-implementation are automatically release when the request is finished. The are some articles in the community here which propose to use optimistic locking instead in a fiori-app with OData (for example with the usage of etag in headers). But this is only possible and integer when the hole solution is using the same locking. So it is not consistent and safe to use optimistic locking from the fiori-app TOGETHER with pessimistic locking with ENQUEUE/DEQUEUE in SAPGui transactions.

So i actually trying hard to use pessimistic locking in our OData-Backend. For this i found a blog describing how to use pessimistic locking by usage of the internal function module 'C_ENQUEU'. 

There is a nice blog which describes this: https://community.sap.com/t5/technology-blogs-by-members/pessimistic-lock-in-sap-netweaver-gateway-o...

Based on this article i am able to the locks which are visible in sm12 and the transactions of the partner-abap solution recognize this lock and handles it the intended way.
Also i am able to release the lock with a subsequent OData-Request.

But actually nevertheless i have a big problem using this solution. If there is no subsequent request from this same user which unlocks the object the lock remains "for ever" in the system or some uses sm12 to delete to lock manually.
So my question is: How i am able to unlock such a lock from another user (the idea is to have normal request to lock if a lock still exists (which works already) and to release this lock (if its longer than a specific time). But there is the second problem: even if i'm able to see when the lock is created in sm12 the FuBa ENQUEUE_READ is not returning this lock creation date/time (only default 0-values are returned for date and time).

Any ideas are hardly welcome
regards and happy eastern
Matthias

[StefanFell]

Hi Matthias,

Maybe you should look on the topic locking not as a part of the data model but as a part of the application. What is unsafe about it, if one application is using pessimistic and another one optimistic locking on the same data? The final goal is to protect your data from inconsistency. Both locking types do the job.

The thing you must take care of in your stateless app is the scenario that the data is locked via ENQUEUE and it cannot be saved right away. Here, the draft table of RAP does the job for saving the data temporary and commit it later.

Sorry for this answer, but the locking via ENQUEUE is meant to be used in an application per user. I doubt that there is a safe way to get around this like you are trying to do. The code of the blog post you are refering to is not safe - and I am not even talking about "clean core".

Regards

Stefan