RE: [Cgi-session-user] (Doc)bug 4.0.2: Automagic flushing

[Sherzod R. <she...@ha...>]

I think I fixed this problem in revision 225 (checkout
http://svn.cromedome.net/ ) by creating driver objects *on-demand*. Now one
can use global session objects and still expect it to be flushed to disk
properly before program terminates.

I just hope I didn't introduce more problems with this "fix".

P.S. I know I did introduce a small problem though. Somehow
$CGI::Session::File::FileName compatibility tests are failing, *again*.

--  
Sherzod


> -----Original Message-----
> From: cgi...@li... 
> [mailto:cgi...@li...] On 
> Behalf Of Charles Bailey
> Sent: Monday, September 12, 2005 1:35 PM
> To: Sherzod Ruzmetov; cgi...@li...
> Subject: RE: [Cgi-session-user] (Doc)bug 4.0.2: Automagic flushing
> Importance: High
> 
> 
> --On September 12, 2005 1:35:53 AM -0400 Sherzod Ruzmetov 
> <she...@ha...> wrote:
> 
> > Charles
> >
> > At first it sounded like you were answering my question on 
> why flush isn't
> > autoflusing sometimes, but I kind of lost you somewhere in 
> the middle.
> >
> >> since the order of global destruction is undefined, it's
> >> possible that
> >> sub-objects held in the session object will be destroyed
> >> before the session
> >> itself, so by the time the the call to CGI::Session::flush()
> >> is made, the
> >> driver may not be defined.
> >
> > Would you be able to re-create this case in a test script? Since
> > sub-objects are held as CGI::Session's attributes, won't they be
> > collected AFTER session object is destroyed?
> 
> Sorry; I think I was a little too concise.
> 
> Perl's (current) global destruction phase differs from the usual GC 
> mechanism in that it doesn't track references or otherwise 
> try to sort out 
> relationships among SVs; it just wades in and starts freeing 
> them up.  That 
> means sub-objects may be destroyed before their parents, etc.
> 
> This isn't usually a problem -- after all, it's global 
> destruction, so 
> presumably nobody wants the data anymore.  However, objects' DESTROY 
> methods are called before the object is deallocated, and may 
> want the data 
> for just a little bit longer.  DESTROY is guaranteed that 
> simple scalars in 
> the object will be around (specifically, objects are cleaned 
> up before 
> non-blessed refs), but sub-objects may have already been 
> dumped, leaving 
> behind an C<undef>.
> 
> To avoid this, one either has to insure that objects are 
> undefined (go out 
> of scope, are C<undef>d, or the like) before global 
> destruction, or the 
> DESTROY method must test for the existence of each 
> sub-object, and recover 
> appropriately if it's "mysteriously" disappeared.  The first 
> option is more 
> common -- it's free if one follows the recommended practice of using 
> lexicals/strict for most purposes, since the lexicals will go 
> out of scope 
> before global destruction starts.  One can also used END 
> blocks or other 
> cleanup handlers to free up objects that need to be global.
> 
> As far as reproducing the problem, here's a short script that 
> demonstrates 
> the basic issue:
> 
>     #!/usr/local/bin/perl -W
>     use Data::Dumper;
>     $foo = bless {NAME => 'globifoo'}, 'Foo';
>     $bar = bless {NAME => 'globibar'}, 'Bar';
>     $bar->{Foo} = $foo;
>     my $mfoo = bless { NAME => 'lexifoo' }, 'Foo';
>     my $mbar = bless { NAME => 'lexibar' }, 'Bar';
>     $mbar->{Foo} = $mfoo;
>     sub Bar::DESTROY {
>         print Data::Dumper->Dump([ $_[0] ], [ $_[0]->{NAME} ]);
>     }
> 
> The tough thing is that, since global destruction is 
> "unordered", it's 
> often a heisenbug.  For instance, if one moves the definition of 
> Bar::DESTROY up in the test script, the problem resolves (on 
> my machine 
> using 5.9.2; YMMV).
> 
> For CGI::Session, the following does it for me:
> 
>     #!/usr/local/bin/perl -W
>     use CGI::Session;
>     $sess = new CGI::Session;
>     print "Session id is", $sess->id;
> 
> No session data is saved to disk, and the "(in cleanup) Can't 
> call method 
> "store" on undefined value" warning is generated.
> 
> > So far few people complained about session not being automatically
> > flushed, but no one was able to recreate the problem in a 
> test script.
> 
> I'm not sure whether they're seeing this problem, but it'd be 
> on the list 
> of suspects if they're using globals and relying on automagic 
> flushing. 
> Turning on warnings and seeing something like the above in 
> the error log, 
> or resolution of the problem when a cleanup handler is added 
> would help to 
> confirm the source of trouble.
> 
> I hope this helps.
> 
> --
> Regards,
> Charles Bailey  < bailey _at_ newman _dot_ upenn _dot_ edu >
> Newman Center at the University of Pennsylvania
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development 
> Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * 
> Testing & QA
> Security * Process Improvement & Measurement * 
> http://www.sqe.com/bsce5sf
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
> 
>