Session Database - User Session Logic

Session Database - User Session Logic

  

I am looking to connect up to the session database in order to build some logic around active and non-active user sessions.  Normally this would be easy to track by a "logout" button but this doesn't capture when a user closes the screen without logging out.

Is there an easy way to connect up to the existing session database?

Hi Daniel,

You can either create a ping mechanism (using JS) that from time to time calls a server action to update the last ping date time and this way keep track of active users OR have some JS code in window.onbeforeunload to call that same server action (although if the browser crashes you will miss the notification).

There must be somewhere that the session "logged out" data is stored as well to compliment this.  If we set the default timeout to 20 mins it would be useful to understand what tables/fields this "timeout" updates.  Rather than one by one we could then understand how many users are concurrently using the application at all times. 

If you consider an active user a user that interacts with the server from time to time, you can then use the On Begin Web Request action to update the user activity. But if you're dealing with a mobile app (the user might be playing around with the app client-side only most of the time) you'll have to do something like I told you in my previous post.

See this Forge component I wrote that addresses these kinds of situations: https://www.outsystems.com/forge/component/1886/login-session-timeout-sample/

It also shows how to do what Joao suggests.

J.Ja

Thanks guys.  My one query with using the OnBeginWebRequest action is because it is essentially running an update on a single table every time a user interacts with the application.  Does this slow down the performance of the application significantly or even lock the table when large user groups are using applications with this logic?

If you're OK with some degree of error, you can track the last update date/time (keep it on a session variable) and only update the user activity entity after some elapsed time.

I suppose tracking that on the session variable and then only updating the table for the user once every minute/couple of minutes or so gives a fairly good granularity.

Updates only lock that one row, and the session DB does a row lock anyways per-request, so it isn't a big deal even in a high volume environment.

J.Ja