How to automatically release locks...

[Former Member]

Hi,

We have users that never close the sapgui session, even when we have setup a timeout to close inactive sessions as they are using several modes. Sometimes they call a transaction and modify some data, this produce a lock in the data table ( calling an enqueue FM ). But user never closes or leaves the transaction, so the screen is in modification mode and the lock remains. Sometimes the locks are there for days, and other processes are really stopped because the locks.

We want to know if its possible to have a lock timeout, for example, if the user has not saved the data or leaved the transaction in 15 minutes, the transaction automatically will go to display mode and it will release the locks.

Any idea ?

Regards,

Joan B. Altadill

[Former Member]

Well, even tho this may be possible to achieve, this whole story is really ridiculous.

Get your freaking users educated would be my first tip.

[Former Member]

Hi,

I understand your answer, I think the same but unfortunately I'm not responsible of user education. I'm only suffering the problems of this behaviours. So I want to know if there is any technical solution...

Regards,

Joan B. Altadill

[Former Member]

<<Irrelevent to the question>>

Hi,

Use transaction sm01 to find the transaction and lock/unlock it.

Run report rslocktrans from se38 and enter the variant value for the desired transaction and the lock/unlock checkbox

Regards,

Gurunath

Edited by: Matt on Feb 25, 2011 11:35 AM

[Former Member]

My issue is not related about locking trasactions. I just want to prevent a DATA lock that remains several days in the system.

Regards,

Joan

[satyajit_mohapatra]

Use SM12 to delete the lock entries manually.......But it's not the ideal way to deal with the issue.....

You may need authorizations to delete other users' lock entries in SM12 as well.....Check with basis....

[matt]

Deleting the lock entries manually would be highly dangerous. The requirement is to switch the locking users to display mode. From my understanding of SAP architecture, this is not possible.

The only solution is user education. For example - find the culprits, delete their sessions (so removing the locks), and then set the validity date of their account to yesterday. In order to use the system again, they'll have to call the helpdesk. When they call the helpdesk, they'll be told the reason their account was locked, was because they abandoned their screens. In most sites, to leave a screen active is a gross security breach and subject to disciplinary action.

matt

[brad_bohn]

Yep, exactly. I have a frequent offender that does that and he gets really pissed when I lock him out of the system. He tried to complain but was told to 'go fix himself' ;-).

If it's such an issue, why not auto-cycle the app servers in sequence every night/early morning at zero-dark-thirty?

[former_member215781]

I am in production support team and face these type of issues several times where the user just enters into some transaction code in change mode and then goes away from the desktop resulting in job failures that update master data.

Can't you setup a background job to run every 12 hours or at night checking if any lock is persisting say more than 12 hours and hence delete that session?

Also, I have one more query, when the user is logged off because of timeout, isn't the locks released?

[Clemenss]

Hi Joan,

from all the answers you see that this is quite a comm thing.

Still, from SM04 user overview, you can kill the users session - if you are authorized - probably you are.

This is not at all dangerous. Killing the session will release the locks.

SAP already created the use of 'optimistic locks'. That means entering the transaction in change mode will set the 'optimistic lock'. Only when data are to be changed (save), the optimistic lock is changed to an exclusive lock. All other users optimistic locks are removed then and can not be changed to exclusive lock - saving will lead to lock error.

Unfortunately, I do not know any SAP transaction that uses this concept. And they don't seem to be willing to change existing transactions.

I may be wrong.

Regards,

Clemens