Re: Live_Objects behavior depends on garbage collection timing

[prev] [thread] [next] [Date index for 2004/07/09]

On Fri, Jul 09, 2004 at 01:07:29AM -0400, Perrin Harkins wrote:
> On Thu, 2004-07-08 at 19:16, Siamak Pazirandeh wrote:
> > Not so. There is another consideration, which is the timing of the
> > garbage collection. This can cause objects that have no reference to
> > them to still remain in the %Class::DBI::Live_Objects hash for some
> > undefined amount of time, until garbage collection sets the weakly
> > referenced objects to undef. In the meanwhile, any retrieves of that
> > object will grab from the cache or DB, unpredictably.
> 
> No offense, but how much do you know about the implementation of the
> garbage collector?  My impression has always been that there is no pause
> between the reference count on an object dropping to zero and that
> object being destroyed.

There isn't. However the timing of the reference count being
decremented on objects going out of scope, especially if being
'returned' as the last value in a block, can be unexpected and has
varied between different perl versions.

Compare these two examples (using perl 5.6.1):

$ perl -MVCt::host_site -w -e 'do { my $foo = VCt::host_site->retrieve(1); }; Class::DBI->dump_object_index'
$VAR1 = {
          'VCt::host|host_id=2' => bless( ... ),            # edited for brevity
          'VCt::network|network_type=vclk' => bless( ... ), # edited for brevity
          'VCt::host_site|host_site_id=1' => bless( ... ),  # edited for brevity
        };

$ perl -MVCt::host_site -w -e 'do { my $foo = VCt::host_site->retrieve(1); 1;}; Class::DBI->dump_object_index'
$VAR1 = {
          'VCt::host|host_id=2' => undef,
          'VCt::network|network_type=vclk' => undef,
          'VCt::host_site|host_site_id=1' => undef
        };

The _only_ difference between the two is the extra "1;" at the end
of the do{} block. Without the 1; (or any other statement) $foo is
the last value in the block and so becomes the 'return value' of that
block which then extends its lifespan. Adding the "1;" (or any other
statement) avoid that.

I _think_ 5.8 'fixes' this so the lifespan of the returned value
is shorter but I'm not in a position to check at the moment.

> I'm sorry to hear that you are having trouble with the single instance
> feature, and I hope you will reconsider trying to find the problem
> rather than just turning it off.

I agree. Please dig deeper. I hope the information above will help you
find out what's going on in your application.

Tim.

p.s. I added this dump_object_index() method to Class/DBI.pm:

  sub dump_object_index { require Data::Dumper; warn Data::Dumper::Dumper(\%Live_Objects); }