Does lock scope '1' work for background execution?

[KKilhavn]

An interface from a system running on someone else's computers (aka in the cloud) occasionally sends two messages for the same ID in rapid succession - the key point here being that the second message is received before we have sent a response for the first message. This shouldn't happen, but it happens.

When this happens they will frequently both fail, as they will create locks that prevent the other from completing all the tasks. So if the first message processes item A and the second message logs that it can't process it because it is locked by the interface user the second message may proceed with item B and when the first message gets to item B it finds that it is locked by the interface user. The incoming messages are processed by a 'System' user (user type B).

I have implemented locking to prevent this, but from my experience and tests it *seems* that lock scope '1' does not work in this context (a web service implementation). If I test the web service from SE80 and use a break point to wait while I start another test a second GUI session the lock prevents execution just as I expected, but since we have these problems in production it clearly does not always work. My question then is obviously; does it *ever* work?
There are subtle hints in the documentation of the lock concept which states that scope '1' belongs to the dialog process, but I haven't found any statement that confirms that background processes are limited to scope '2' (the update task).

Does anyone have similar experience, or can even someone from SAP confirm that lock mode '1' only is relevant when you have a dialog work process?

[Sandra_Rossi]

Difficult to comment about the problem you have in production, but generally speaking, I don't think the lock scope depends on the context. Are concerned only the work process (whatever it's dialog or background, whatever the user type) where the lock is done, and eventually the scope extension during the optional Update Task.

Concerning your problem, I would more focus on SAP notes (or more complete SAP documents) which talk about the synchronization of the Enqueue Server across several application servers.

[KKilhavn]

Thanks for your input, Sandra. You write that you don't think the lock scope depends on context. Neither did I, but I can't find anything conclusive in the documentation. That's why I am hoping a SAP employee (or someone else) can provide an answer without "I think" 🙂

Scope extension to update task is only relevant for scope 2, and one of the terms 'dialog' or 'interactive' seems be used every time some aspect of lock scope 1 is explained.

[former_member660513]

Could it be that the web service is opening a new (user) session? That could be the only explanation - user sessions/LUWs...

[KKilhavn]

I've been assuming that two web service calls will be executed in two different sessions as they are two different external calls.

That said, I don't see the relevance of your comment. If you lock (even with only scope '2') an object by starting a transaction in one session and start the same transaction for the same object in another session you will get a foreign lock error. The point of scope '1' is that it will keep it locked even after a COMMIT WORK statement and the behaviour I observe is not consistent with that.