Release remaining dataset locks when file editor stops

[John-A-Davies]

The purpose of this item is to release locks the WEBUI user has taken on datasets in the cases when the user has not specifically released them.

Parent epic: #498

Dataset locks will persist unless explicitly released. The WEBUI user can do this by closing the file editor tab for that dataset. The problem to solve is that if

1. the file editor window is closed
2. the browser is closed
3. the user session times out
4. the client becomes inoperative

then the remaining locks will not be released, so the locked dataset can't be accessed.

[John-A-Davies]

Workaround: If you re-open the file editor tab for the locked dataset, then close that tab, the lock will be released.

[John-A-Davies]

Locks are taken and released by the server on command from the client. If the client stops for any reason, the server must release the locks on its behalf. So the server must monitor the client to see if it is still active. This will be implemented by a keep-alive heartbeat sent from the client to the server. If the server detects a missed heartbeat, it will release all locks requested by the client.

A server can have many clients. Each client session is started by a user. One user can start many sessions. The server must release only those locks taken by that client session.

Implementation.

Add 2 fields to the lock table in the server

1. session ID
2. flag, to indicate whether a heartbeat has been received in the past time window

Logic.

1. Whenever the server detects the heartbeat, it sets the flag

2. the server periodically checks the flag at the end of each time window
   3. If the flag is set, the session is alive; unset the flag
   4. If the flag is not set, the session is dead; release all locks for that session.

[John-A-Davies]

#498

[John-A-Davies]

I looked in zss for is some identifier connected with the client process that's running the file editor window, for example on the HTTP request. However, Irek informed me that zss doesn't store any client info. It only verifies the cookie by decoding it using a symmetric key.

[John-A-Davies]

If you watch the zssServer.log while the client is connected, you will see that a group of messages appear every few minutes, provided the user has the filestore tree window open in the file editor. The messages look like this

AUTH: tokenCookieText: i7sBFyeIL5VhuOgH1w8yn6jvAs9xxUuFfhh03b+q/bdiIE161e0vUJ0=                                                                           
decoded session token data for text i7sBFyeIL5VhuOgH1w8yn6jvAs9xxUuFfhh03b+q/bdiIE161e0vUJ0=                                                              
00000000  8BBB0117 27882F95 61B8E807 D70F329F  A8EF02CF 71C54B85 7E1874DD BFAAFDB7 |.....h.n/.Y.P...y....E.e=.......|                                     
00000020  62204D7A D5ED2F50 9D                                                     |..(:N..&.|                                                            
colon pos 7;decoded data token:                                                                                                                           
00000000  8BBB0117 27882F95 61B8E807 D70F329F  A8EF02CF 71C54B85 7E1874DD BFAAFDB7 |.....h.n/.Y.P...y....E.e=.......|                                     
00000020  62204D7A D5ED2F50 9D                                                     |..(:N..&.|                                                            
EBCDIC session token:                                                                                                                                     
00000000  D4C1D9C8 D6D3D37A 84F9F183 F5F18385  F7848286 F6F4F4F0 7A84F9F1 83F5F1F7 |MARHOLL:d91c51ce7dbf6440:d91c517|                                     
00000020  F084F9F6 F9F5F6F4 F7                                                     |0d9695647|                                                            
colon pos2 24;                                                                                                                                            
decodedTimestamp=d91c51ce7dbf6440;now=d91c51ceb7dbf445;difference=3a1c9005;interval=ffffff593a400000;tokenUID=d91c5170d9695647;serverUID=d91c5170d9695647 
returning TRUE                                                                                                                                            
serveLoginWithSessionToken: start. response=0x14CAA02C; cookie=0x14CC0448                                                                                 
serveLoginWithSessionToken: end                                                                                                                           

You will see that this comes from

httpserver.c, L2805
    AUTH_TRACE("colon pos %d;decoded data token:\n",colonPos);
    AUTH_DUMPBUF(decodedData,decodedDataLength);
    AUTH_TRACE("EBCDIC session token:\n");
    AUTH_DUMPBUF(plaintextSessionToken,decodedDataLength);

which is called, a few levels up, by handleHttpService, and up to serviceLoop , then runServiceThread which creates the thread. So that's an example of creating a thread to perform a loop that waits for its service to be called.

So in that service, you could perform

Whenever the server detects the heartbeat, it sets the flag

On the client side, you have to issue a call to that service every time window.

[1000TurquoisePogs]

We ended up implementing this for now zowe/zss#355 and it seems to be working simply. So, lets close this epic as completed. If specifically pessmistic writing is needed in the future, we'll take a look at this work again.