At 9/15/2001 10:47 PM (Saturday), Solon Edmunds wrote:

>So as I prepare to re-write this (for me) complex architecture ~ I
>really appreciate all feedback very much to help me do it right. Sincere
>thanks!

Connection pooling does not have to be all that complicated unless you have
to take into account some subtle coordination mandated by your application.

I would define an object (a singleton factory object) from which each
transaction gets a connection. This request of the factory would normally
be done just before the transaction is started. I presume you can find the
right place to add this.

That connection factory returns an unused one if it has one on hand or
otherwise creates a new connection. Internally it keeps a list of
connection references which are available and currently unused.

The transaction code just has to remember to notify the factory when it is
finished using a connection. That would normally be done right after the
commit or rollback. I also presume you can find the right places for this.

That's about it for the simple connection pooling approach. The size of the
pool will grow to be the size of the maximum number of simultaneous
transactions, of course, but that may be OK depending on your application.