Forum OpenACS Development: Standard Openacs-4 aolserver .tcl config file?

Is there a standard AOLserver .tcl config file that people are
using to run openacs-4? I'm just going to modify the acs-4 tcl
file that I was using for Oracle, I guess.
Posted by Vinod Kurup on
I've also uploaded my config file (which I use for testing on postgres and oracle) to file-storage.
Posted by Don Baccus on
How many pools does ACS 4 need, does anyone really know?  Three have
worked for me.  Will it work with two?  Does it ever need four?  Why
don't I just RTFM myself?  (good question - is it documented in the aD
supplied docs?)

Also, the names "main", "subquery", and "log" are obsolete, though
I've been using them myself since my ACS 4 .tcl files are derived by
simple edits on my existing ACS 3 .tcl files.

"pool1", "pool2", and "pool3" make more sense, there's no longer any
semantic meaning to the names.

Posted by Jerry Asher on
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.)

With ACS 4 you need as many pools as you want to allow nested queries. It doesn't matter what the pools are named, either (from my reading of packages/acs-tcl/tcl/10-database-procs.tcl). For example with a normal configuration (main, subquery, log) you can't nest four layers deep:
db_foreach depth_1 { select 'depth 1' from dual } {
    db_foreach depth_2 { select 'depth 2' from dual } {
        db_foreach depth_3 { select 'depth 3' from dual } {
            db_foreach depth_4 { select 'depth 4' from dual } {
                set success_p 1
Without getting an error:
Ran out of database pools (subquery main log)
Personally I wish the db_* api had been designed to allow you to define pools per database so that you could use the same API and AOLserver instance to talk to both, say, Oracle & Postgres (or Solid or whatever) without having to use the ns_db API directly. (Perhaps with one of them being the "default" and the others being specified via a switch, like db_foreach foo_query -database solid ... Pools of pools, so to speak.)