On Sun, Sep 15, 2013 at 6:16 PM, Linreg <linreg@gmx.net> wrote:
Hi Dave,
>
> This change is unrelated to porting to pure C++, and needs to be
> discussed and (if acceptable) implemented as a separate patch. I'm not
> convinced it's an appropriate change at all - I certainly work with
> customer who do not use a connection pooler for various reasons, and
> rely on the pooler in the agent to prevent large numbers of
> connect/disconnect cycles, which amongst other things use resources
> unnecessarily, and can fill up audit logs.
A little addendum:
- connection pooling per Job is not a problem. This changes send i in the next week.
- connection pooling of all jobs has no effect in your code. The function clearconnection released connection-objects before it can be reused after one mainloop cycle. I think. I may be wrong.
so connection pooling per Job should be enough. What do you mean.
Why don't you think it works? The logic at the moment is basically
while (1)
{
Look for jobs to run
If jobs are found, run jobs, each in a separate thread
Else if no jobs were found, purge connections
}
So if you have multiple jobs running in each loop cycle (i.e. the agent is busy), connections are retained. They're only clear if there was no work to do (and then, it'll only affect connections that aren't in use by longer running job threads).