Another session state question

robertv has asked for the wisdom of the Perl Monks concerning the following question:

Here is what I want to do.
1) When a new user comes to my site I want to get a database handle for them that will be used as their $dbh for that session.
2) Time out the $dbh & connection if the user hasn't done anything within ? 15 min ?
3) Kill the $dbh and connection if the browser window is closed.

Here is the idea to do it.....
Include a 1 pixel frame at the top of the page with the target page being a .pl that gets the $dbh. Then passes it encrypted as a cookie (that will expire on browser or window close)(personally, I hate sites that leave cookies on my computer, and routinely delete them all!)
Then when I need the $dbh I'll use the $query->cookie() business.
Here are my questions:
1)Now I know I can kill the connection through a javascript OnWindowClose() funtcion, but is there a simular perl way?
2)If I don't specifically exit() the script that gets the $dbh will the connect stay open? Otherwise this whole idea will not work. If not how do I do it.

I am up for alternative methods, but anything to do with Appache is out. My service provider uses Zues.
Thanks, Robert V.

Comment on Another session state question

Replies are listed 'Best First'.
Re: Another session state question by perrin (Chancellor) on Sep 23, 2002 at 22:00 UTC
Oh boy, where to start? Well, to put it simply, none of this will work because you can't serialize database handles. They are not just a simple collection of Perl data, since they involve XS code, open sockets, file handles, etc. Why are you trying to do this anyway? If you just want to improve performance over standard CGI, use fastCGI with Zeus.	[reply]
Re: Another session state question by sauoq (Abbot) on Sep 23, 2002 at 22:51 UTC
The big catch for you is your second question. If I don't specifically exit() the script that gets the $dbh will the connect stay open? You can maintain persistent connections to the database but you'll need a persistent process to manage them for you. I don't know much about Zeus. I think if you are dependent on your service provider for things like which server software will run, then developing this much complexity into your application is probably not a real option for you. The good news is that you rarely really want to do what you are attempting anyway. The approach will tend to make your performance graphs look like a staircase because you are allocating resources to each user and tying those resources up even while the user is idle. With a good web application a user will only consume resources during an actual request at least as far as CPU and RAM go. (Disk usage is, of course, a different story.) Maintaining persistent DB connections makes the most sense in a case where users can share those connections. The bad news is that you should probably bring your design back to the drawing board. -sauoq "My two cents aren't worth a dime.";	[reply]
Re: Another session state question by Cody Pendant (Prior) on Sep 24, 2002 at 01:02 UTC
I know I can kill the connection through a javascript OnWindowClose() funtcion, but is there a simular perl way? For the record, no. To ask this question is to misunderstand the nature of client/server. How will the server know what happens on my computer? -- `($_='jjjuuusssttt annootthheer pppeeerrrlll haaaccckkeer')=~y/a-z//s;print;` [download]	[reply] [d/l]
Re: Re: Another session state question by robertv (Initiate) on Sep 24, 2002 at 18:06 UTC
From what little I have read, couldn't you call a .pl page that read the cookie and used the value to explicitly $dbh->finish() / $dbh->disconnect(); rather then put up a pop up window? Robert V.	[reply]
Re: Another session state question by robertv (Initiate) on Sep 23, 2002 at 23:16 UTC
Thanks for the help. I will trash the persistant conection. I will have to double check, but I don't think my service provider compiled perl with fast CGI suport. Robert V.	[reply]