What I really dislike on this discussion is, that it mixes
two topics that are, IMO, really different:
- Using a pool of database connections from an application,
typically a threaded application.
- Accessing a database connection which really lives on
another machine via some sort of remote access protocol;
SOAP, Corba have been mentioned in the discussion, the
DBI Proxy is using a more lightweight protocol (from the
view of Perl) implemented by RPC::PlServer and
RPC::PlClient
In the past Tim Bunce has proposed to implement the pool via
a special DBI driver, DBD::Pool say. For example this could be
done via a DSN like
DBI:Pool:pool_maxwaiting=10;dsn=DBI:Oracle:trueDsn
much in the style of DBD::Proxy. I still believe that this
approach has incredible advantages, in particular
- it solves the problem that the connection obtained from
the pool has to match certain settings; for example the
last user of the connection might have set RaiseError => 1
altough the initial value was different. A DBD::Pool
driver could quite well be aware of the initial value
and possible changes
- it would allow to turn the pool on or off by simply
changing the DSN
- any portable DBI application could make use of such a
pool
What remains is the question of using a remote connection.
First of all, note that DBD::Pool would allow to maintain
the pool on both sides of the remote connection: It could
be on the server side (which is carrying the actual
database connection) and on the client side. For example,
the latter would make sense in the case of Apache.
Bye,
Jochen
