On our site we create a new CGI::Session object at the beginning of
the request, so that it can be used anywhere in the web code.

However, sessions are rarely written to, so at the end of the request
I'd like to avoid actually writing out a new session to backing store
unless a param actually got set. The expense of writing out new
sessions, and cleaning them up later, has become significant.

I couldn't figure out a way to do this with the public CGI::Session
API, but I managed to get it to work this way:

1 my $session = CGI::Session->new(...);
2 $session->_unset_status(CGI::Session::STATUS_MODIFIED);
3
4 # ... web code gets executed here ...
5
6 if (!$session->_test_status(CGI::Session::STATUS_MODIFIED)) {
7 $session->_reset_status;
8 }
9 $session->flush();

I initially reset the modified bit on line 2. Then on line 6, if the
modified bit is still unset (meaning no param was ever set), I clear
the status entirely, which causes the flush() on line 9 to be a no-op.

Is there a better, e.g. supported, way to do this? How do other people
prevent new sessions from getting written to the backing store
unnecessarily?

Thanks
Jon


------------------------------------------------------------ ------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com

On Tue, Jan 26, 2010 at 7:42 PM, Jonathan Swartz <SWARTZ [at] pobox.com> wrote:
> On our site we create a new CGI::Session object at the beginning of the
> request, so that it can be used anywhere in the web code.
>
> However, sessions are rarely written to, so at the end of the request I'd
> like to avoid actually writing out a new session to backing store unless a
> param actually got set.

It might be simpler to just write immediately when you set a param.
It's simple and foolproof, and it's only a negative for performance if
you normally set multiple params in a single request.

If your ultimate goal is to fix performance on your servers, I'd
recommend looking at using encrypted data in a cookie and ditching
server-side session storage.

- Perrin

On Jan 27, 2010, at 2:45 PM, Perrin Harkins wrote:

> On Tue, Jan 26, 2010 at 7:42 PM, Jonathan Swartz <SWARTZ [at] pobox.com>
> wrote:
>> On our site we create a new CGI::Session object at the beginning of
>> the
>> request, so that it can be used anywhere in the web code.
>>
>> However, sessions are rarely written to, so at the end of the
>> request I'd
>> like to avoid actually writing out a new session to backing store
>> unless a
>> param actually got set.
>
> It might be simpler to just write immediately when you set a param.
> It's simple and foolproof, and it's only a negative for performance if
> you normally set multiple params in a single request.
>
> If your ultimate goal is to fix performance on your servers, I'd
> recommend looking at using encrypted data in a cookie and ditching
> server-side session storage.
>

True. My solution only involves a couple of lines of code, so it isn't
going to get much simpler. It would just be ideal if I could use the
public API. And this seems like an optimization that others might want.