From: Dave R. <au...@ur...> - 2001-08-08 22:46:35
|
On Wed, 8 Aug 2001, Karl Seguin wrote: > Most (if not all) of the information I have concerning using DBI with > Mason > comes from 1 question in the FAQ. This leads me to believe one of > three > things: > - Mason or mod perl are not the ideal solution for database driven > sites, or > - My strong dependency on databases is unique, or finally; > - People who write the mason documentation don't realize the dominance > of database driven sites. Actually, the correct answer is that Mason and DBI are orthogonal. Mason is Perl. If you can use DBI from a regular Perl script than you already know how to use it from a Mason component. > Don't get me wrong, I can open a connection through mason to a database > and do eveyrthing I need with it. But database connections, and > recordset fetching are by far the number one cause of latency on > high-traffic websites, and I want to know all the ways to do it; along If your mysql server and web server are running on the same box then I doubt that this is the case. Mysql is extremely quick to create a new connection. > and limitations of each. I think *if* mason is capable of driving > heavy database driven sites, far more documentation, examples, and > discussion need be made about it. I'm not sure this is true. The Mason documentation assumes at least a reasonable level of familiarity with Perl. If you're not really comfortable with Perl, DBI, etc then using Mason isn't going to make it any easier. Its not going to make it any harder either. > In handler.pl (outside of "sub handler") > > { package HTML::Mason::Commands; > use vars qw($dbh); > use Apache::DBI; > } > I believe that the above code makes the $dbi variable globally > accessibly, and that it imports the Apache::DBI package. Yep, that's all correct. > next I have in sub handler: > > my $datasource = "DBI:mysql:database=blah;host=localhost"; > my $username = "blah"; > my $password = "blah"; > my $attr = { RaiseError=>1 ,AutoCommit=>0 }; > # Apache::DBI->connect_on_init($datasource, $username, $password, > $attr); # Apache::DBI->setPingTimeOut($datasource, 0); > $HTML::Mason::Commands::dbh = DBI->connect($datasource, $username, > $password, $attr); > > ok, so the first 4 lines are DBI related. The next 3 lines are where > I start getting confused. The 2 commented out lines come from the faq, > whereas the bottom line comes from the Admin Manual (on how to create > global > varibables). AS you can see, I decided to follow the admin manual's > suggestion, since it makes sense to me. Am I supposed to be using one > or the other? Or are they supposed to be used jointly? If I have the > choice, what is the difference, and which do I want. How does > Apache::DBI->connect_on_init($datasource, $username, $password, $attr); > assign a value to the $dbh global I made? Apache::DBI->connect_on_init doesn't assign anything to your global. It just makes sure that whenever a new Apache child process is created that a new DB connection is opened so that it is available to the first request that comes in. You actually want to put that line outside of your handler sub cause it only needs to be run once at server startup. > With the code that I have now, i don't have any problems, because I > have a nice $dbh variable i every page which I can do anything "man DBI" > tells me. but what if I didn't have access to handler.pl ? Would my > only alternative be to connect from each component to the database? ala: > > use Apache::DBI; > my $dbh = DBI->connect(...); > ... > my $dbh->disconnect(); > > > Obviously this costs me a connection each time I hit that component. > This is how ASP does it with ADODB, there are no persistent connections > (unless ODBC / OLE DB are doing something in the background??) and I > never really saw it as being a huge problem. Are database connections > more costly using DBI and that's why we want to make them persistent? > or is windows just sloppy and offers us no solution. Windows is sloppy cause database connections _can_ be expensive, dependeing on the RDBMS (Oracle is expensive, for example). However, by using Apache::DBI you've turned $dbh->disconnect into a no-op so you can just get rid of it (or leave it there if it makes you happy). > and then $dbh->connect(...) in each necessary component - though I > don't see that saving me much overhead. Actually, it would cause using Apache::DBI caches connected database handles. > Hope my concerns make sense. Somewhat. But I think your problem is more confusion about DBI and mod_perl than Mason. -dave /*================== www.urth.org We await the New Sun ==================*/ |