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."