Re: Judiciously avoiding DESTROY method for CGI::Session clobber prevention

You've got it backwards -- if you don't let the session object get destroyed, no other process will ever be able to see the changes you made. The session has to get destroyed in order for the data to be saved.

If you truly need exclusive locking (not very likely, but some session uses need it), you should look at Apache::Session instead, which provides that.

Comment on Re: Judiciously avoiding DESTROY method for CGI::Session clobber prevention

Replies are listed 'Best First'.
Re^2: Judiciously avoiding DESTROY method for CGI::Session clobber prevention by rlucas (Scribe) on Jun 08, 2005 at 21:44 UTC
Hmm, yes and no. CGI::Session has a manual flush() method, and I have the habit of calling a flush to disk after a set of changes. Plus, my teardown methods in my CGI::Apps do normally close out and flush the session. So the DESTROY flush is bad here, because I'm already flushing when I want it, so DESTROY's flush is when I don't. I agree with you and jasonk that Apache::Session is generally better suited for concurrency, although I really like a lot of things about CGI::Session (specifically, the ability to have Data::Dumper serialization and /tmp file storage -- very transparent for debugging). Furthermore, although locking would be the full solution here, my app does not require it, and I would view that as a significant negative (due to possible blocking). All of the "hard" transactional stuff I'm doing is done with real DB transactions -- the session stuff is fairly "soft."	[reply]
Re^3: Judiciously avoiding DESTROY method for CGI::Session clobber prevention by perrin (Chancellor) on Jun 08, 2005 at 21:59 UTC
The right answer is to make sure it always gets destroyed, not to prevent it from getting destroyed. Otherwise, you can always have changes that have not been synced. If you really want to do things differently, you can subclass it and change the DESTROY method to not flush. You should make it check for unsaved changes and at least send a warning to the log though.	[reply]