Forum OpenACS Development: db_release_unused_handles

Posted by Antonio Pisano on
As a latecomer on OpenACS, I have never made use of db_release_unused_handles in any of the code I have written and I often wondered what the purpose of this proc is.

To my understanding, it used to be the case that, at least in certain situations, one had to force the release of db handles manually, or else they would stay "taken". Is this something we should still worry about?

What is a concrete example of idiom where I should definitely use this proc?

Thanks for any answer


Posted by Claudio Pasolini on
Dear Antonio,

in the old days memory and resources were more valuable than today and so it happened to me sometimes to use db_release_unused_handles.

Let's suppose you have a long running program that reads a number of rows building a list of lists and then processes heavily every single line before finishing: I think it could make sense to release the handles before starting the processing.


Posted by Brian Fenton on
I think it's never really needed in modern OpenACS. My memory isn't reliable, but if I recall correctly back in the Arsdigita days one sometimes had to manually fetch a handle using "ns_db gethandle", which then could be released using " ns_db releasehandle". At some point, OpenACS changed it so that scripts automatically released handles, so the manual practice went out of use.

See here for some old history

Posted by Gustaf Neumann on
As a latecomer on OpenACS, ...
well, you are a member of OpenACS since 12 years.

are you asking for curiosity, or do you suspect an issue with this?

db_release_unused_handles calls "ns_db release handle", which returns a given handle allocated by a connection thread to the pool of db-handles (db connections) managed by NaviServer/AOLserver (the code for these servers is different). More precise, this is called in the cleanup traces, where also global variables are deleted, etc.

But notice, one might have as well long-running requests, maybe threads running in the background, or running in separate threads, where db-handles are allocated in a certain situation, but normally not used. These can become an issue, since the typical recommendation for db-handles is based on potential current connection threads, without considering background threads. Also notice, that the there are as well other mechanisms in place to clean up handles based on usage count or usage timeouts.

db-connections are expensive, since these require (at least in the case of PostgreSQL) separate processes with their own caching management. So on machines with very constraint resources, these can make the difference (thinking also on embedded applications and IoT). The goal is to use as few as possible db-handle without the need to wait for it when these are needed.

Answering unasked questions:
* Do I have to care as an OpenACS user about the handling of DB connections? Not really.
* Can intentional releasing of db-handle be important for certain applications? Probably.
* Should I add db_release_unused_handles calls to my self-developed OpenACS applications? No, usually the framework handles this sufficiently.
* Can I remove all ns_db_release_unused_handles in the OpenACS core packages? I would not recommend this (unless there is a real need)

I see many calls to "db_release_unused_handles" in the www directory of application packages, such as "survey" or "evaluation". Without looking into the details, i would suggest that these calls are not necessary and can be removed.

Posted by Antonio Pisano on
Thanks to all of you for your answers!

...I have certainly been around a while in absolute terms, but not as long as this proc 😊

As you might have noticed, lately I have created a couple automated tests for the public api and the proc popped up a few times. Sometimes, for instance in, the comments would seem to suggest that this was no longer necessary, hence my curiosity.

When I have time I would like to come up with a small example where I can really see the proc releasing some handle, I think this will make clearer whet the purpose is.

Thanks again!

Posted by Gustaf Neumann on
If you want to "see" the difference, notice that handle management is a two step process: (a) allocating db handles in the pool, and (b) gabbing db handles in (connection) threads. The easiest spot to see the effect of (b) is "ns_db currenthandles" (in case you use NaviServer.