[Network disconnection] Session Management & Locks

[guillaume-hrc]

Hi,

I am posting in Web Dynpro ABAP but the subject may apply to all (stateful ?) Web technologies (ITS, BSP, WDA, WDJ, ...), I guess.

Let's say you have a very bad network and that you lost the connection to your SAP system very often.

The session on the SAP system stays alive as long as the (client) timeout is not reached.

This means that the locks that have been set are also kept during this time.

If the same user got a new connection, he/she should be able to release previous locks and start again whatever process he/she was working on (I am not saying from the same point in time though...)

Problem is that even if you detect it is the same user accessing the very locked object, the DEQUEUE functions are not going to work since he/she has started a new LUW (Logical Unit of Work)

What are the best ways to handle this situation?

Thanks in advance for your inputs.

Best regards,

Guillaume

[thomas_jung · Accepted solution]

>Let's say you have a very bad network and that you lost the connection to your SAP system very often.

That really shouldn't matter in the Web Dynpro (or BSP) world. You don't have a heartbeat to the server like you do with the SAPGUI. Techincally HTTP is already stateless. Only via a session ID that posts back to the server with each request can the server reconnect you to the same user session. You can completely disconnect your network connection, reconnect and your application will still work.

Only if the user's browser completely crash on the desktop can you really have a hanging session. In this situation, the browser doesn't get the chance to send the logoff script command.

Not much you can do about this however. If you use the logon screen you can turn on the multiple logon check and allow users to end other sessions. Otherwise there isn't much you can do short of using Basis admin tools to go into the system and kill zombie sessions.

[guillaume-hrc · Accepted solution]

Hi Thomas,

This is clearer.

Thanks for your (very!) quick answer.

Scenario is the following classic one: network got lost, at the next HTTP reques the browser returns an error so the user closes the browser window and start with a new window.

Hence, the session ID got lost and there is no way for the user to terminate the preivous session properly (am I right?)

So there is chance to:

1) Dequeue locked objects (because of the LUW principle -> new LUW, no dequeue) ?

2) Terminate the hanging session programmatically (but how to differentiate between hanging and ... not intermittently active from the server point of view) ?

3) Call the part of the logon screen code to prompt the user to terminate old session (that seems like a very good idea) but within an already opened session (of course we are using SSO so we do not need logon screen)

Many thanks in advance.

Best regards,

Guillaume

[thomas_jung · Accepted solution]

>Scenario is the following classic one: network got lost, at the next HTTP reques the browser returns an error so the user closes the browser window and start with a new window.

Yes, if the user closes the browser while the network connection is still lost then it won't be able to send the logoff script. The user should instead press refresh.

>1) Dequeue locked objects (because of the LUW principle -> new LUW, no dequeue) ?

No you can't dequeue outside the original user session. This is intentionally a protection. Once a lock is set in a LUW it is assume it maintained (no late locking checks). If the LUW is released externally it can lead to inconsistent data in the database. SAP errors on the side of safety when it comes to locking. Better to make a user wait until the session times out then to get corrupted data.

2. and 3.) for the same reasons as above, SAP is very cautious about allowing anything but kernel code to kill user sessions. This is controlled by the few applications allowed to use it and should be used by customers directly.

[guillaume-hrc · Accepted solution]

Hi,

Disclaimer : As stated by Thomas Jung, use the following approach at your own risk!

Should someone go for this not-recommended -by-SAP solution, one possible approach would be to :

1) retrieve the name of the user holding the lock in sy-msvg1after calling the FM 'ENQUEUE_Exxx'

2) if it is the very same user, then :

3) read lock details with FM 'ENQUE_READ2'

4) use these details (little conversion needed to respect FM parameters types) with FM 'ENQUE_DELETE'

5) perform the initial 'ENQUEUE_Exxx' --> that should be OK now

Once again, mind the disclaimer!