Server Connection Recovery

A VLF-WIN Framework can be configured to handle a temporary loss of connection to a server. For example, this might happen when a user's laptop moves out of range of the wireless base station.

The Framework can be configured to check the server connection:

• Prior to a move by the user to any business object or application

• Prior to executing a command

• At intervals specified by the designer.

The Framework checks the connection by attempting to run a simple function on the server.

If the reconnection attempt fails, or if the function runs but does not return an OK value, then the Framework can respond in a number of ways:

• The default response is to stop Framework activity, advise the user, and to attempt reconnect when the user clicks ok.

• The application designer also has the option of writing their own server connection test function. This could be coded to return a connection error code, even if the function runs ok. This might be useful for advising all Framework users that an upgrade is in progress and they need to log off. (See example function UF_SYSBR/UFU0004)

• Programmatic connection checking in Framework filters and command handlers is also available, using the #avFrameworkManager.avCheckConnection method. This would need to be coded into filters just prior to doing a database search, or coded into command handlers just prior to doing a save.

• Filters and command handlers can also detect that connection recovery is underway by listening for events signaled by the Framework manager such as avSessRecoverStarted, avSessRecovered and avSessRecoverFailed.

A server connection check will not happen while your RDML(X) code is executing unless the code specifically requests avCheckConnection.

Even if the "Check before executing command" option is checked, you will still need to include invoke #avFrameworkManager.avCheckConnection in your command handlers and filters prior to doing any server database IO (for example, prior to doing searches and saves).

To use connection recovery you need to make sure any database commitment control boundaries you use do not span user interactions. A database commitment control boundary cannot span a session reconnection.   

If you are using connection recovery you should avoid using session based values (e.g. the server *JOBNBR) as 'keys' to information in your application session because they will probably change after a reconnection.   

The session recovery feature deals with LANSA super-server sessions only. It does not recover a 5250 RAMP session.    

If the Framework is locked by Framework locking, connection checking and recovery is not performed, except for these situations:

• Automatic connection checks that occur at timed intervals

• Specific filter and command handler usage of avCheckConnection