Sven,
> I'm familiar with connect_cached, however I don't think it will work
without
> further changes because the connection gets torn down when the object goes
> out of scope, doesn't it?
My guess is that the object does not get torn down. I'm not sure how
familiar you are with garbage collection and references in Perl, so forgive
me if I am a bit verbose.
Consider this code
##############################
my %cache ;
sub get_hashref
{
my $x = {} ;
$cache{$x} = $x ; # cache $hr
return $x ;
}
my $hashref = get_hashref() ;
undef $hashref ;
%cache = () ;
##############################
get_hashref() returns a random anonymous hash. $hashref in this example
refers to a hash. Now, the question is, when does the REFERENCED hash get
destroyed? It does _not_ get destroyed on the "undef $hashref ;" line,
because there is still a reference to it in the %cache hash. However, once
we call "%cache = () ;", all references to the anonymous hash have been
cleared, and the hash will get garbage collected.
Now, think about this when you think about DBI->connect_cached(). When you
call connect_cached, you get back a database handle. However, that database
handle is also stored somewhere in DBI's internal cache. Therefore, even
though *your* reference of the database handle goes out of scope, DBI is
still referencing the connection. Therefore the object will not be torn
down.
However, calling $dbh->disconnect() on the object WILL tear it down. So the
key is this:
Beginning of script, $dbh->connect_cached();
End of script, $dbh->commit() but NOT $dbh->disconnect.
This way, all changes are saved but your connection will still remain
active.
> Do you have an idea how persistency can be integrated into the DBH plugin?
> I think it's a functionality that will be useful to many people.
>
> Perhaps the handles can be stored inside a package-level variable
> in the CAP:DBI module?
> There could be a MD5-hash over the parameters (host, port, db, user,
password)
> so it doesn't accidentally hand out the wrong database handle
> if different requests ask for different handles.
I think that this solution would be overkill. You'd just be replicating the
work that DBI already does. It would be much simpler to just change the
DBI->connect(...) call to a DBI->connect_cached(...) call. Based on my
explanation above, this should work just fine. It is also safe to do this
inside the CAP:DBH module since the module is sloppy and never calls
disconnect.
Hope that this clears things up a bit!
Josh
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
