Persistent HTTP Connections ala Apache::DBI

[Hans Juergen von Lengerke <le...@sixt.de>]

I'm working on a web application which obtains data via a legacy system
rather than DBI. Using DBI is (unfortunately) not an option. The machine
where the web application runs cannot run the legacy system. Thus, the
setup looks somewhat like this:

   DB  <=>  DB Query (Legacy)  <=>  Apache/mod_perl  <=>  Client

I was thinking to make the connection between DB Query and
Apache/mod_perl using HTTP, so there will be an Apache running on the DB
Query tier for access to the legacy system.

What I'm interested in, is a persistent HTTP connection between the
Apache/mod_perl tier and the DB Query tier. I'm thinking of a ChildInit
handler which opens up a HTTP/1.1 connection to the apache sitting on
the DB query tier. The connection would use keep-alive, which of course
would be enabled and set to high timeout values on the DB Legacy tier.

This is more or less what Apache::DBI does, just in this case it should
be something like Apache::PersistentHTTPConnection. Unfortunately, I
haven't found such a thing.

Has anyone done such a thing before? Can someone point me to docs or
modules which could help doing this? Or is this whole idea maybe just
plain stupid? Are there obvious caveats I haven't thought of?

Any comments are welcome.

Re: Persistent HTTP Connections ala Apache::DBI

[Rob Nagler <na...@bivio.biz>]

> Has anyone done such a thing before?

No doubt.

> Can someone point me to docs or
> modules which could help doing this?

Perhaps raw sockets might be a consideration.  However, Apache is
great middleware, so I tend to use it in cases like this.  You might
want to use a session-based approach between the db-Apache and the
app-Apache.  The db-Apache would cache the connections to the legacy
DB returning sessions the app-Apache which would cache them as well.
You'd get the performance of cached DB connections without having to
ensure the HTTP connections remain alive across app-Apache queries.

When a session times out on the db-Apache tier, just rollback
(assuming your DB is transactional) and put it in the free pool for
new sessions.

> Or is this whole idea maybe just
> plain stupid?

I don't think so.  I assume the DB connection cost is high (on the
order of seconds) iwc you need some way to cache connections.

> Are there obvious caveats I haven't thought of?

Garbage collection is an issue.  How do you know when to timeout
(rollback) queries on db-Apache?  Are the queries "atomic" to
app-Apache, i.e. within a single end-user HTTP request or do they span
multiple end-user requests?  (This latter a good idea, imo.)

mfg,
Rob