How do I have multiple gen_servers, behind a single name, all serving requests?

[Christian S]

Creating connections to databases tend to take some time, most
solutions involve having N connections open in a pool that application
code check out while operating on the db.

As I have found out, database session tend to have a state. For
postgres a prepared statement is given a name that is local to that
session, hidden from other sessions to postgres.
So checking out a connection from a pool, one would have to make sure
these exist by preparing them again, each checkout. Maybe not that
costly in most real situations, but I thought it could be engineered
better:

The idea I got was that you have:
 * one front-end gen_server,
 * it is registered to the name one like to expose,
 * it keeps a fifo or stack of anonymous worker gen_servers
 * to pass on requests any non-busy worker gen_server, quickly going
back wating for more requests
 * and receving info about workers becoming available again.

This would distribute requests over several worker gen_servers. Is
there anything in OTP which does this already? A gen_server option i
missed? pool and overload seem to be concerned with cpu load. I just
want to have several gen_servers so each one can have its own
connection to the database, to avoid the cost of opening new
connections and tap in to the sometimes very good multithreading in
rdbms.

Pooling application gen_servers rather than database connections is
one step up in abstraction. Making it cleaner to write solid
gen_servers that implement "business logic" (sorry for the buzzword).
I mean, succinctly formulated operations the application needs from
the db, such as
decrement-N-units-from-account-A-if-the-balance-is-high-enough:
bank:withdraw(N, A).

Typically gen_servers act as a form of synchronization device, but
here the databases go to great length to handle transactions and their
collisions well.

<<Is this something that could be beneficial for other applications?
given the new SMP scheduler? dns-resolvers come to mind, oddly enough
a remote and of low local processing need database lookup as well.>>