[Dbix-class] Live object index support ported

Sam Vilain sam at vilain.net
Sun Jul 31 04:30:49 CEST 2005


Matt S Trout wrote:
>>Does it help keep 2 objects that are really the same row in sync?  If  
>>so, what is a good reason for even having 2 objects that refer to the  
>>same row, in the same process at the same time?
> Basic purpose: to ensure that if you grab the same record somewhere in
> your code while an object for it is still in scope somewhere that you get
> back the same object. It at least means you can't end up with 2 objects
> that refer to the same row in the same process.

For the sake of comparison and a reference working implementation, let
me explain how this works in Tangram.

Tangram::Storage has a cache in ->{objects}, a hash from the OID (class
ID + primary key ID) to the object.  Using Scalar::Util qw(weaken), this
can be a "weak" reference that drops once the object falls out of scope.

However, it is a bad idea to keep these objects around after you commit,
unless you are very careful to implement some kind of object versioning
system (ie, each record has a version number that must match before
updating can succeed).

If not, you end up with all manner of "dirty read" problems.

Without the cache there at all, there would be another set of equally
nasty problems; if your database correctly implements "consistent read",
then this might be OK most of the time; but still could lead to some
very subtle bugs.

To make things easier, Tangram also provides a method to explicitly dump
the cache; $storage->unload_all().  If you are using it with
Class::Tangram, calling $storage->unload_all("clear_refs") will pass
each object that is still in the object cache the "clear_refs" message,
which is effective at breaking circular references.

Sam.



More information about the Dbix-class mailing list