Best Practice - ending a session?

Hello all,

Can anyone please tell me what the best practice is to close/end a web session? This would include properly closing all database connections too, and ensuring that all data from previous use is properly destroyed/removed from memory in both the server side and client side.

Thank you,
Tim

[quote=110897:@Tim Seyfarth]Hello all,

Can anyone please tell me what the best practice is to close/end a web session? This would include properly closing all database connections too, and ensuring that all data from previous use is properly destroyed/removed from memory in both the server side and client side.

Thank you,
Tim[/quote]
Please! This is an area I am struggling with right now. There seems to be remnants of sessions lingering on the server, and I am having a hard time understanding the cause of that. I am currently creating test programs to see if I can figure this out.

Seems to me the best way is to set Session.TimeOut sensibly, and do house cleaning in the TimedOut event. Normally this will end the session and destroy all associated processes and their controls.

So you are still experiencing the ghosts of sessions past ?

Your message prompted me to check my own server. Three ghosts :

[code]USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND

bu1471a 21308 2.8 1.8 19156 9332 ? Ssl Jul12 62:04 /home/bu1471a/domains/match-software.com/cgi-bin/delivery --port=8080
bu1471a 3857 2.9 1.9 19256 9720 ? Ssl Jul09 187:20 /home/bu1471a/domains/match-software.com/cgi-bin/mail/MatchMail --port=17053
bu1471a 26504 2.9 1.7 19268 9112 ? Ssl Mar13 5248:25 /home/bu1471a/domains/match-software.com/cgi-bin/m/Mail --port=39346[/code]

Although I have set TimeOut these processes are old. The one from March 13 especially. Had not noticed it before.

In all three cases the time is whacked. Could it be the problem ?

I have driven a stake through the heart of these undead by killing them, so now things are tidy, but it is a tedious chore. At least now I don’t have herds of zombies as I experienced before.

I submitted this feedback 34438 - WebSession ‘ghosts’ chewing up memory, to try to get to the bottom of the matter. I had previously submitted this one that may be related but was too specific to a function 34335 - Can’t kill websession with App.SessionAtIndex(i).Quit. 34335 has ‘fixed’ status, but I am not sure if that cures 34438.

That is exactly the question - it is hard to know what house cleaning to do, and how to “destroy” everything - properly.

Maybe one of the web gurus like Greg will jump into this thread.
Tim

It is for you to decide what to save. As for destructors, Xojo should do it transparently upon quit, but you may have something else in mind…

Hello Michael,
I save what I need. There is no problem there.
The problem is that not everything is being destroyed, or being destroyed timely - as both you and Mark have also seen. The purpose of my original question was to determine if maybe I am not doing something I should be, to tell or allow xojo to do its house cleaning job.

Ok, first of all, Session.Timeout and Session.TimedOut have NOTHING to do with closing a session. They are there for the purpose of knowing that a browser has been idle too long. If you set the timeout to 180 seconds, the TimedOut event will fire if there are mouse or keyboard events for three minutes. Every mouse or keyboard event resets the timer.

Next, if we fixed a bug in 2014 r2 which caused WebPages to not release in certain circumstances, which would in turn cause sessions to not go out of scope (a circular reference). It is still possible for you to cause memory leaks like this yourself by holding onto references to controls, WebPages and websessions, so make sure you set them to Nil when you’re done with them.

Hello Greg.

Can you please advise an answer to where to find the answer to my original question.

Thank you,
TIm

Anything that you open, you should close. If you have a property for a database connection, close it when you’re done with it. As I said, we fixed some bugs recently and WebSession.Quit should be more reliable now, but keep in mind that Session.Quit is immediate.

Fwiw, when everything is working properly, sessions should quit on their own about 3 minutes after the user leaves your app. But this still relies on sessions being able to close properly.

With our framework, there’s no data “stored” on the client side. If you want the browser to delete data on a web page, close it. If you want a user to disconnect completely, direct hem to a URL that is not part of the app using ShowUrl.

Hello and thank you Greg.

You mention WebSession.Quit and Session.Quit - I will have a look at those in the help. Yesterday I was looking for an example, but could not find anything. I also looked at some of the web examples for clues there too, but did not see anything that jumped out.

To be completely clear, things like this should be done - and in this order(?)

  1. Special objects on pages should be closed ( I do not use any now, but have read others having what appears to be “special” to me at least)
  2. Existing pages should be closed
  3. The database should be closed, then the object set to Nil - correct?
  4. Send to a different URL (to clear anything on the browser side?)
  5. Use WebSession.Quit or Session.Quit to completely terminate the session.

Another question would be, from where should each of these be executed - specifically the .quit actions?

Thank you again,
Tim

But quitting in TimedOut is fine, right ?

Yes, but I’d also suggest directing the user to another URL, preferably something not connected to your app so it doesn’t actually make a new session.

I was thinking more of controls from other developers. If there are any special requirements for closing those controls, then yes.

You can do that. Keep in mind that just redirecting the user to another URL will clear a lot of data from the browser already. It’s always a good idea to close WebPage instances that you are not using just from the standpoint of memory. iOS devices are currently limited to 25MB of memory per web page, but in a Xojo web app, that represents an entire Session.

The database should be closed. I suggest having a property on the Session for the DB connection. That will automatically get destroyed once the session goes away.

Yup. Something not associated with your app.

Just Session.Quit. The Session object in your project is a Subclass of WebSession. I often use them interchangeably when talking about session methods, properties and events. [quote=111045:@Tim Seyfarth]Another question would be, from where should each of these be executed - specifically the .quit actions?[/quote]
From wherever the decision was made to close the session. If you’ll be going to all this trouble, make a method on the Session class so you can call it from wherever you want.

Of course. You are right. I shall implement that. Thank you.

Thank you Greg - your answers were exactly what I was looking for. Will check my code and implement your recommends.

Tim

One more - [stupid] question: how to redirect to a different URL?

Thanks,
Tim

http://documentation.xojo.com/index.php/ShowURL

Thank you Frederick.
Tim

In my start to finish web app (LinkShare) video series for subscribers I have a short segment on this. When the timeout event is fired I present a dialog to the user to stay logged in. If they don’t respond within 60 seconds I redirect them to a URL that says they were logged out due to inactivity.

More information at http://xojo.bkeeney.com/XojoTraining/