Deeper explanation of how the locks are set and released, and how to recognize if the situation where the locks remain is caused by the enqueue service or the application being executed.
At the start of an SAP transaction, two owners are always created who can request locks: the dialog owner and the update task. The application uses the _SCOPE parameter to specify which of the two owners should actually own the lock, and therefore defines the lock duration with respect to an SAP LUW. When the update task is called, it inherits the lock.
The COMMIT WORK statement is executed at the end of the transaction. The lock is removed in the majority of the cases after it, but this depends on the application, as it is responsible for setting the _SCOPE parameter.
Locks remains set until you either call the corresponding DEQUEUE function module, or close the transaction that executes an implicit DEQUEUE_ALL. The application is responsible for calling the dequeue function, so that's why it’s always recommended to check these remaining locks-problems further with the application team. Generating an enqueue logging could be useful to check which locks are generated, when and for which objects. More information on SAP Note 2126913.
2126913 - "ENQU: The enqueue log".
The session frees all its resources even if the application did not release them explicitly. This means that if some locks are left by the application, they will be released automatically by the task handler after rdisp/gui_auto_logout seconds. The taskhandler always send DequeAll during deletion of sessions.
We have to take into account that the timestamp of the lock correspond with the transaction execution not to the time when the log was set. Does the lock remain beyond rdisp/gui_auto_logout ? SAP Note 43614 describes the different scenarios an possible solutions.
43614 - Lock entries remain after end of session
If the problem is that the lock is hold for a long time we should take into account that this is normal as the application is being executed. It will be needed to check if the transaction is still running. This could be checked in SM50 or in case of update records in SM13 transactions. Quite big selection criteria or dialog transaction going over different screens before the application performs the COMMIT WORK are the most common ones.