If I rewrite connect_db as: my $dbh; sub connect_db { if (! defined $dbh) { $dbh = DBI->connect("dbi:SQLite:dbname=".setting('database')) or die $DBI::errstr; } return $dbh; } will the application use a single connection for all connections under all perl webservers (in-built, mod_perl, Starman, Twiggy etc.). If that is true, a line to that effect in an appropriate place in the tutorial would emphasize the persistent features of the solution. Also, are any hooks run when the application instance is destroyed? If there are, implementing a graceful closing of open DB connection(s) might provide a valuable lesson in the Tutorial. Thank you.
Gurunandan Bhat wrote:
If I rewrite connect_db as:
my $dbh; sub connect_db {
if (! defined $dbh) { $dbh = DBI->connect("dbi:SQLite:dbname=".setting('database')) or die $DBI::errstr;
} return $dbh; }
will the application use a single connection for all connections under all perl webservers (in-built, mod_perl, Starman, Twiggy etc.).
I am interested in a definitive and clear answer as well. I tried the above method a while back, and kept on getting errors on transactions (I am using SQLite). Since I am using Apache, I added `PerlModule Apache::DBI` to my httpd.conf, and went back to a simple $dbh creation instead of checking for `defined $dbh` Knowing the correct way to implement this, perhaps even the way*s* for different servers (I am assuming different web servers might have different ways of implementing persistent connections) would be tremendously helpful.
If that is true, a line to that effect in an appropriate place in the tutorial would emphasize the persistent features of the solution.
Also, are any hooks run when the application instance is destroyed? If there are, implementing a graceful closing of open DB connection(s) might provide a valuable lesson in the Tutorial.
Thank you.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
-- Puneet Kishor http://punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Fellow http://creativecommons.org/about/people/fellows#puneetkishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu --------------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science ===========================================================================
On Sat, Jan 8, 2011 at 8:26 PM, Puneet Kishor <punk.kish@gmail.com> wrote:
Gurunandan Bhat wrote:
If I rewrite connect_db as:
my $dbh; sub connect_db {
if (! defined $dbh) { $dbh = DBI->connect("dbi:SQLite:dbname=".setting('database')) or die $DBI::errstr;
} return $dbh; }
will the application use a single connection for all connections under all perl webservers (in-built, mod_perl, Starman, Twiggy etc.).
I am interested in a definitive and clear answer as well. I tried the above method a while back, and kept on getting errors on transactions (I am using SQLite).
Admittedly, this (using a common database handle for all connections) might not neccesarily be a Good Thing precisely because of transaction issues (and consequently slowdowns because of locks) that it leads to. However one way to handle transaction issues could be to have a per-session database handle. Requestor passes a session id to connect_db, which sees if the session has been allocated a handle and generates a new handle if not. If the session is an old one, it merely picks up the correct previously allocated handle and returns it. If per-session persistence is possible, then you should not have transaction issues. Is that possible?
Since I am using Apache, I added `PerlModule Apache::DBI` to my httpd.conf, and went back to a simple $dbh creation instead of checking for `defined $dbh`
Knowing the correct way to implement this, perhaps even the way*s* for different servers (I am assuming different web servers might have different ways of implementing persistent connections) would be tremendously helpful.
If that is true, a line to that effect in an appropriate place in the
tutorial would emphasize the persistent features of the solution.
Also, are any hooks run when the application instance is destroyed? If there are, implementing a graceful closing of open DB connection(s) might provide a valuable lesson in the Tutorial.
Thank you.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
-- Puneet Kishor http://punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Fellow http://creativecommons.org/about/people/fellows#puneetkishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu --------------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science ===========================================================================
On Saturday, January 8, 2011 at 12:31 PM, Gurunandan Bhat wrote:
On Sat, Jan 8, 2011 at 8:26 PM, Puneet Kishor <punk.kish@gmail.com> wrote:
Gurunandan Bhat wrote:
If I rewrite connect_db as:
my $dbh; sub connect_db {
if (! defined $dbh) { $dbh = DBI->connect("dbi:SQLite:dbname=".setting('database')) or die $DBI::errstr;
} return $dbh; }
will the application use a single connection for all connections under all perl webservers (in-built, mod_perl, Starman, Twiggy etc.).
I am interested in a definitive and clear answer as well. I tried the above method a while back, and kept on getting errors on transactions (I am using SQLite).
Admittedly, this (using a common database handle for all connections) might not neccesarily be a Good Thing precisely because of transaction issues (and consequently slowdowns because of locks) that it leads to.
However one way to handle transaction issues could be to have a per-session database handle. Requestor passes a session id to connect_db, which sees if the session has been allocated a handle and generates a new handle if not. If the session is an old one, it merely picks up the correct previously allocated handle and returns it. If per-session persistence is possible, then you should not have transaction issues.
Is that possible?
heh heh! I have no idea, although, the logic that you describe seems very, well, logical. Should work. I just don't know how to do it. If someone who is first-hand experienced in this, and especially with different web servers, would do a little write-up, that would be tremendous. -- Puneet Kishor Sent with Sparrow
Since I am using Apache, I added `PerlModule Apache::DBI` to my httpd.conf, and went back to a simple $dbh creation instead of checking for `defined $dbh`
Knowing the correct way to implement this, perhaps even the way*s* for different servers (I am assuming different web servers might have different ways of implementing persistent connections) would be tremendously helpful.
If that is true, a line to that effect in an appropriate place in the tutorial would emphasize the persistent features of the solution.
Also, are any hooks run when the application instance is destroyed? If there are, implementing a graceful closing of open DB connection(s) might provide a valuable lesson in the Tutorial.
Thank you.
On Sun, Jan 9, 2011 at 12:04 AM, Puneet Kishor <punk.kish@gmail.com> wrote:
On Saturday, January 8, 2011 at 12:31 PM, Gurunandan Bhat wrote:
On Sat, Jan 8, 2011 at 8:26 PM, Puneet Kishor <punk.kish@gmail.com> wrote:
Gurunandan Bhat wrote:
If I rewrite connect_db as:
my $dbh; sub connect_db {
if (! defined $dbh) { $dbh = DBI->connect("dbi:SQLite:dbname=".setting('database')) or die $DBI::errstr;
} return $dbh; }
will the application use a single connection for all connections under all perl webservers (in-built, mod_perl, Starman, Twiggy etc.).
I am interested in a definitive and clear answer as well. I tried the above method a while back, and kept on getting errors on transactions (I am using SQLite).
Admittedly, this (using a common database handle for all connections) might not neccesarily be a Good Thing precisely because of transaction issues (and consequently slowdowns because of locks) that it leads to.
However one way to handle transaction issues could be to have a per-session database handle. Requestor passes a session id to connect_db, which sees if the session has been allocated a handle and generates a new handle if not. If the session is an old one, it merely picks up the correct previously allocated handle and returns it. If per-session persistence is possible, then you should not have transaction issues.
Is that possible?
heh heh! I have no idea, although, the logic that you describe seems very, well, logical. Should work. I just don't know how to do it.
If someone who is first-hand experienced in this, and especially with different web servers, would do a little write-up, that would be tremendous.
You could try something like this (NOT TESTED): my $session_dbh; sub connect_db { my $session_id = shift; if (! exists $session_dbh->{$session_id}) { my $dbh = DBI->connect("dbi:SQLite:dbname=".setting('database')) or die $DBI::errstr; $session_dbh->{$session_id} = $dbh; } return $session_dbh->{$session_id}; }
-- Puneet Kishor Sent with Sparrow <http://www.sparrowmailapp.com> <http://www.sparrowmailapp.com>
Since I am using Apache, I added `PerlModule Apache::DBI` to my httpd.conf, and went back to a simple $dbh creation instead of checking for `defined $dbh`
Knowing the correct way to implement this, perhaps even the way*s* for different servers (I am assuming different web servers might have different ways of implementing persistent connections) would be tremendously helpful.
If that is true, a line to that effect in an appropriate place in the tutorial would emphasize the persistent features of the solution.
Also, are any hooks run when the application instance is destroyed? If there are, implementing a graceful closing of open DB connection(s) might provide a valuable lesson in the Tutorial.
Thank you.
On Sat, 2011-01-08 at 14:48 +0530, Gurunandan Bhat wrote:
If I rewrite connect_db as:
my $dbh; sub connect_db {
if (! defined $dbh) { $dbh = DBI->connect("dbi:SQLite:dbname=".setting('database')) or die $DBI::errstr; } return $dbh; }
will the application use a single connection for all connections under all perl webservers (in-built, mod_perl, Starman, Twiggy etc.). If that is true, a line to that effect in an appropriate place in the tutorial would emphasize the persistent features of the solution.
A single connection per process, I believe. For instance, if you run it under Starman, which will start a certain number of spare processes (5, by default) I'd expect each of those processes to have their own database connection. Incidentally, Dancer::Plugin::Database makes this kind of thing very easy indeed :) Cheers Dave P -- David Precious <davidp@preshweb.co.uk> ("bigpresh") http://www.preshweb.co.uk/
On Jan 10, 2011, at 4:53 AM, David Precious wrote:
A single connection per process, I believe. For instance, if you run it
N.B. I can't speak for Starman or other deployments as I have no experience. But for straight mod_perl & DBI: Certainly a single connection per process is the right model under a straight mod_perl / DBI model. The idiom I use is: our $dbh; # DBI .... In every request: $dbh = db_connect() unless $dbh; where db_connect() does the usual DBI->connect() and returns the handle. If you try to reuse the DBI handle across fork(), then DBI itself will start throwing errors, subject to DBI's RaiseError / PrintError configuration. In other words, allocate a global handle for the DBI connection, and initialize it by opening it. Don't fork and reuse the global handle without re-opening it in the child. The only way to get into trouble is the DBI handle gets initialized before the child forks. This means if I need to read state from the DB that I want inherited by all children, then in the function called at httpd init time, I open the db, read the state into ram, then close $dbh and undef it. You also may find this DBI & mod_perl info helpful as the DBI persistence issue is pretty well covered: http://modperlbook.org/html/20-1-Persistent-Database-Connections-with-Apache... http://dbi.perl.org/docs/ HTH, -- jeff
participants (4)
-
David Precious -
Gurunandan Bhat -
Jeff McCarrell -
Puneet Kishor