[Koha-devel] about C4Connect

[Pat Eyler]

On Mon, 10 Jun 2002, Alan Millar wrote:

> On Mon, Jun 10, 2002 at 10:52:42PM +0200, paul POULAIN wrote:
> > I i'm right, every DB function begins by a $dbh=&C4Connect.
> > Connecting to a DB is a HIGH time-cost function.
>
> I agree.  The current method works fine for small, lightly loaded
> systems.  If we want Koha to scale, and want it to be portable to
> other DB engines where the DB open may be an even bigger
> performance hit, we should change the current practice.


One solution (at least on the high end) is to use mod_perl and Apache::DBI
to intercept the connect and disconnect calls and use an existing pool of
connections instead.

mod_perl safety in the rest of the scripts (running them with
Apache::Registry as opposed to making them handlers), is going to be a big
part of making the system scale.   (Being prepared to run Koha as a
two-tiered system and planning on spreading the app over several servers
is going to be another bit to look at.)

The real trick is going to be in ensuring that we're able to use tricks
like this without requireing that the small libraries (and home libraries)
don't need to take on the overhead of mod_perl.

>
> > The solution to this problem would be to have only one $dbh=&C4Connect
> > at the beginning of every .pl script, this $dbh variable being used by
> > every sub.
>
> I think this is where we need to go.  Yes, it is the most work, but I'd
> rather see us phase in the right solution over time than change a bunch of
> subroutines quickly for a short-sighted solution.
>
> > One solution would be to rebuild all sub calls to add a dbh parameter,
> > but i'm sure there is a solution to declare a global variable, which
> > would be used if there is no "my $dbh" in the .pm sub...
> > What's the best solution in Perl to do this ? ("our" may be used with
> > packages, but what i want is to have the C4Connect at the beginning of
> > every .pl script)
>
> I'd like to avoid undocumented side effects in subroutines.  What happens
> at some point in the future when you might want two different databases
> open, but you can only use the subroutine on one of them because the
> database handle depends on a global variable with a fixed variable name?
> "Oh, we'll never need that...." :-)
>
> I just spent the last week unravelling a script that didn't do "use strict",
> and chasing down the side effects of undeclared variables and global
> variables used in subroutines was a mess.  Let's not do more of that :-)
>


Yes, 'down this path lies madness'.  Down this path also lie hideous
debugging and maintenance nightmares and huge mod_perl issues!  Let's
stick to the connect and disconnect per module and look to Apache::DBI to
help with the *really* big sites.

-pate

> - Alan
>
> ----
> Alan Millar     --==> am12 at bolis.com <==--
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/koha-devel
>