Most session implementations (including beaker) have a timeout setting to decide how long the session data should remain valid (server side, independent of the cookie expire settings). When you access request.session it's going to load the session from storage and update the last accessed time as a way of keeping the session alive. If it didn't work this way you'd run into scenarios where a user is live and active on your site but keeps getting timed out based on when their session first started.
Though I can't explain why the connections are staying open. On Thu, Feb 7, 2013 at 9:44 AM, Wyatt Baldwin <[email protected]>wrote: > > > On Thursday, February 7, 2013 7:32:00 AM UTC-8, Jonathan Vanasco wrote: >> >> what are you using to manage sql connections in your app ? >> >> i dropped pyramid's transaction management and went with my own >> solution - which registers a db cleanup routine via a tween. >> depending on how your connections are managed, you might be missing a >> cleanup. >> >> please post the fix when you figure it out. i'm considering a similar >> scheme, but haven't gotten to this yet. our production sessions are >> on Memcached now, and i use a secure cookie to autologin if it's >> lost... but I want to consider moving to mysql based sessions, which >> can sit on their own server ( which is entirely separate from our >> postgresql data store ). >> > > I've partially figured it out, and it looks like it's an issue with my > configuration, not pyramid_beaker. > > The way I had things set up, *every* request (and, in particular, static > requests) was accessing the `request.session` property. I've changed things > so this isn't the case, but what I can't figure out is why that would > really matter. I mean, you should avoid accessing the session if you're not > using it, but merely touching the session property shouldn't cause a DB > connection, and even it does, the connection should still be closed. > > Basically, my current "solution" is simply to not access the session as > much, which isn't very robust. > > One thought on what may be causing this is that some of these requests are > relatively long-running. Increasing the pool size for the session engine > may help... > > I'll post more later. > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/pylons-discuss?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
