Re: [Cgi-session-user] session data not being saved till flushed.

[Mark S. <ma...@su...>]

On Mon, Feb 13, 2006 at 09:24:40AM -0500, James.Q.L wrote:
> 
> --- Mark Stosberg <ma...@su...> wrote:
> 
> > On Sat, Feb 11, 2006 at 11:30:47PM -0500, James.Q.L wrote:
> > > HI,
> > > 
> > > I am using C::S 4.03 and the session data is not saved unless i call flush(). The doc claims
> > > otherwise, "Normally it will be called for you just before the program terminates, or session
> > > object goes out of scope, so you should never have to flush() on your own."
> > 
> > Hello James,
> > 
> > There are now several bug reports filed about related behavior,
> > including one I filed myself just a few days ago:
> > 
> > http://rt.cpan.org/Public/Bug/Display.html?id=17541
> > 
> > This much is clear:
> > 
> > - For some people flush() used to happen automatically with 3.95, but quit working
> >   with 4.00 (and still isn't fixed in 4.03).
> > 
> > - It's possible for third party modules to break the automatic flush() behavior, which 
> >   I've confirmed myself. This can happen by creating a circular reference, so that the
> >   DESTROY method isn't invoked as expected. 
> > 
> > My proposal to address the situation is quit relying on flush() happen
> > automatically, and recommend that people use an explicit flush()
> > instead, which works reliably for everyone.
> > 
> > That's what I'm doing. Actually, since I use CGI::Application, I just
> > call flush() in teardown() and forget about it the rest of the time. 
> > This currently does have some overhead because it means that a session
> > ma created at that moment so that flush() can be called on it!
> 
> how did CGI::Session handle the flush overhead before? 

In the original design, there was no significant overhead. flush was
called as part of DESTROY(), which happens when an object goes out of
scope, and is not to be confused with an END{} block, which happens at
the end of every request.  flush() was only called on objects that were
created, and only tried to update the storage backend if there was
anything to flush.

My suggestion for use with CGI::Application is more like the END{} block
case, which happens at the end of every request. Since a session might
not otherwise be created during a specific request, there's overhead 
in the possibility of a session being created for no real use. 

This is easily addressable by adding like "session_is_loaded()" method
to CGI::Application::Plugin::Session. Then you can check to see if a
session actually exists first, and only call flush() if there is one
there.

	Mark