Live_Objects behavior depends on garbage collection timing

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

Since the .96 release, I've been working on fixing my code with respect to the new caching behind the scenes (Live_Objects). I figured that As long as I clean up the scope of all my Class::DBI objects, I should be ok. 

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.

This gives sporatic bahavior, depending on the timing of the garbage collection. Sometimes we get a cached object, and sometimes we get fresh data from the DB. Imagine if you're trying to do a "Increment" operation on a database field. This would wind up only working *sometimes*, depending on the timing of garbage collection!!!! @#$%!

Example:

do {
    my $cd  = Music::CD???>retrieve(1);
}
print STDERR Music::CD->dump_object_index();

# add in Class/DBI.pm:
sub dump_object_index {
    use Data::Dumper;
    print Dumper(\%Live_Objects);
}

========================== output:
[max@localhost tmp]# perl dbi_cache_test.pl
$VAR1 = {
          'Music::CD' => bless( {
               trackid' => '25150'
}, 'Music::CD' )
};
As you see, the retrieved record is still in the Live_Objects hash... as garbage collection has not yet kicked in. Keep in mind that This behavior may not be repeatable, as the timing of garbage may be different under different circumstances.

Suggestion:
It is understandable that a caching system based on weak refs will have this kind of behavior. However, this behaviour should not be the default, but at the most, be an opt in behavior. I highly recomend that this behavior be turned off by default. It ovbiously makes sense in some scenarios, but will break lots of code out there which don't anticipate this new wide sweeping behavior.

Another suggestion is that caching behavior be configurable on a per table basis, and be stored as class data, perhapse via singletons.

For now, I am going to do as others on the list seem to be doing, which is to override _init and turn off this caching behavior alltogther.