RE: [CDBI] CDBI, Oracle, and mod_perl

[prev] [thread] [next] [Date index for 2005/08/15]

Will,

Thanks for summarizing the issue so thoroughly.  We do have the ability
to tweak our DBI connections site-wide, so that approach sounds
promising.  Does DBIx::ContextualFetch add significant memory overhead,
processing requirements, or the like?  In reading the docs, it seems
that one of the purposes of the Ima::DBI project (which
DBIx::ContextualFetch appears to be a part of) is to make caching
easier, which seems like a Good Thing.

Also, can you elaborate (or point me to an existing elaboration) on the
concerns you cited regarding class data and symbol-table manipulation.
We are considering Class::DBI as part of a broader research of the
Catalyst web framework.  It seems likely that different web apps in
Catalyst would need to access the same database classes, so more info on
this would be useful.

Thanks again.

- Simon

-----Original Message-----
From: William Ross [mailto:will@xxxxxxx.xxx]=20
Sent: Sunday, August 14, 2005 9:39 AM
To: Simon Miner
Cc: classdbi@xxxxx.xxxxxxxxxxxxxxxx.xxx
Subject: Re: [CDBI] CDBI, Oracle, and mod_perl

On 14 Aug 2005, at 06:32, Simon Miner wrote:
> Hi,
>
> (Note: I originally posted this message to the groups.kasei.com =20
> version of this list. Then I saw the note on the wiki that the =20
> mailing list had been moved. I apologize if sending this message =20
> results in a duplicate post.)
>
> My organization uses mod_perl and Oracle to run our high traffic e-=20
> commerce web site.  Our site currently using DBI (via Apache::DBI) =20
> to interact with its database.  We would like to bring Class::DBI =20
> into the mix, but we are concerned about the two-connections-per-=20
> process problem mentioned in the ReUseLegacyDBIHandle page on the =20
> Class::DBI wiki (http://wiki.class-dbi.com/index.cgi?=20
> ReUseLegacyDBIHandle).
>
> Perrin Harkins' wiki page on overriding the do_Main() method to =20
> accommodate mod_perl (http://wiki.class-dbi.com/index.cgi?=20
> UsingWithModPerl) seems to provide a potential solution, but it =20
> also appears to contradict the assertion on the =20
> ReUseLegacyDBIHandle page that you cannot use a normal DBI handle =20
> for a Class::DBI handle.  There appeared to be some back and forth =20
> on this in a previous thread on this list (http://groups.kasei.com/=20
> mail/arc/cdbi-talk/2005-02/msg00218.html), but I couldn't see any =20
> resolution coming out of it.
>
> Has there been any further development on this matter?  I would =20
> like to recommend Class::DBI for our e-commerce web site, but we =20
> just could not abide doubling our Oracle connections.  As has been =20
> mentioned, they are just too resource intensive.  Is it possible to =20
> (safely) set up a database connection for a Class::DBI object using =20
> a DBI handle?
It's very simple and perfectly safe, so long as you take the right =20
precautions. Forgive me if I go on a bit:

Under normal circumstances Class::DBI uses a handle provided by =20
Ima::DBI, which uses a clever but now rather eccentric system of =20
closures to achieve persistent but economical database links. It does =20
this by injecting a db_[connection name] method into the namespace of =20
the class calling connection() or set_db(). In the case of Class::DBI =20
the connection name is always 'Main', so the database handle is =20
always retrieved by calling db_Main. Most serious users of cdbi end =20
up subclassing this runtime method either to relax cdbi's class-level =20
attachment to its database or to supply a database handle they've =20
already got.

A cdbi object can make use of any database handle that has the root =20
class DBIx::ContextualFetch (which is a DBI subclass of Tony's that =20
adds some shortcuts and defaults. The wisdom of this decision is =20
often debated). This inheritance should have no effect on the use of =20
your handle by other machinery unless there happens to be a clash of =20
method names, so the easiest answer is to tweak your existing =20
connection pool so that it contains cdbi-compatible handles, and then =20
put in your base class a db_Main method that retrieves its connection =20
from this pool.

The problems mentioned on the wiki arise when you can't change =20
existing code, but still want to use existing handles. If you really =20
want cdbi's convenience then it's possible to inject the necessary =20
methods into your handle when it arrives in the cdbi application (ie =20
in db_Main, again), but I don't think I would recommend investing =20
that much customisation work right now. There's a lot of forking and =20
blustering going on at the moment and it would probably be more =20
sensible to wait a month or three and then see which of the resulting =20
solutions serves you best.

(also, I haven't used Oracle, but I get the impression that cdbi =20
isn't all that well adapted to a setting where connections are very =20
expensive. Perhaps someone else here has suggestions.)

It's also worth mentioning that under mod_perl, or in any other =20
persistent environment, you have to pay attention to cdbi's use of =20
class data and symbol-table manipulation. If you're using the same =20
classes for more than one application, or to access more than one =20
database, then you will need to take extra care about =20
compartmentalising data and configuration settings and returning the =20
right handle for each request.

hth

will