I don't know how many pools OpenACS 4 needs. But I believe that if people desire, in OpenACS 5, all that is needed is one pool.
Does it matter though?
The benefit of having separate pools is that you can informally designate each pool for a specific type of task, and AOLserver will ensure that a page can only allocate once (once not one) from each pool before releasing the handles from that pool. That helped keep buggy pages from running off with all the connections at once.
The reality is, everyone uses main, and then for subqueries, everyone pulls from subquery or log irrespective of the "designated" use for that pool.
So way back when, with the original db interface, it was important to have separate pools and to configure them precisely for your website's needs because the number of connections you needed was a line item in your budget.
Is that still the case? With PostgreSQL, at least, connections are relatively inexpensive right? (not quite free, they do cost memory). What are the licensing models of the other databases that ACS may target?
Anyway, with the new db architecture, where pages no longer call gethandle or releasehandle on their own, it may be reasonable to relax AOLserver's "allocate all at once" constraint. What I envision is that the db_* commands would somehow interact with AOLserver turning off the "allocate all at once" checking, and they could allocate from one pool as they need. Presumably, the db_* interfaces would not be guilty of running off with all the handles.
The benefit would be for a cheaper and better configured site. Instead of having n pools, where you keep and pay for a few spare connections in each pool to keep from starving any pool, you could pay for just a few spare connections in the one pool that the db_* interfaces use.
It makes sense to do this iff database connections are costly and/or having a cleaner system (without the legacy main, subquery, or log pools) is deemed worthy.
One other benefit of a db cleanup for ACS 5 would be the ability to run multiple, completely separate ACS installations out of the same AOLserver process.
The hardcoding of main, subquery and log ensure that you can only run one ACS instance at a time in one AOLserver process. Even in the AOLserver 4 architecture, db pools (and their name and namespace) will be shared amongst every server (virtual host) within the same AOLserver process. (And I was hoping that nsvhr/nsunix/nssock questions would go away with ACS 4, but they won't.)
