Re: Db pool [was: My little comments to CPP code]

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

sergey@total-knowledge.com wrote:
>>>>>           
>>>> Of course not. It's all parsed for you already. Just add an app-level
>>>> parameter
>>>>         
>>> Ok, I'll get it from ServerConfig::GlobalContext using
>>> getGlobalParam("num_threads") in InitServlet.
>>>       
>> Let me repeat. No.  Just add an app-level parameter.
>>     
>
> Ok, inside <app> scope in engine.xml
> <num_connections value="bla-bla"/> will be added.
>   
Almost there. Now look at the samples for the proper syntax....
>>> Hereis the list of events that may happen to connections:
>>> 1. Connection can be opened.
>>> This will happen in uudb() class' constractor, db.open() will be called.
>>> uudb object created at InitServlet::init()
>> During request processing?
>>     
>>> 2. Connection can be closed.
>>> This will happen in uudb() class' destractor, db.close() will be called.
>> During request processing?
>>     
> Maybe that's how things should be:
>
> We'll have to override init() and destroy() for each servlet. I'm not sure
> what's the best way to organize it, certainly it's not pretty to do it
> inside of each servlet itself. Maybe we should use EnvironmentSetupServlet
> where among with overriden init() and destroy() will be other common for
> all servlets functionalities(like, for example, getting sessionid from
> HttpSession object, etc..). This EnvironmentSetupServlet will be included
> in Header.cpp.
> In EnvironmentSetupServlet::init() we open the connection and call login()
> stored procedure. All needed parameters for login() will be taken from
> request.
> In EnvironmentSetupServlet::destroy() we close the connection and call
> logout() stored procedure.
> Also perhaps we can retrieve DB handle in EnvironmentSetupServlet too.
>   
I think you missed the fact that connections do not have to be closed
nor are necessarily open when pool returns them. You are, however,
right in that the login() stored procedure should be called every time
connection is retrieved, and logout/cleanup should be called every time
connection is returned to the pool. I think it is best to tie these to pool
itself, in order to avoid forgetting to call these by accident.

Another thing you are forgetting about is when init() and destroy() are
called.

> Can't quite figure it out.
> I see that you use Task object in CThreadPool implementation, perhaps I
> should have something similar in uuDBPool. The queue consists of Tasks,
> and Task is actually the job that pool does(getConnection(),
> releaseConnection()).
> Maybe you give me hints?
>   
I meant for ThreadPool to be only an example on how CWaiters can be used,
not as reference in implementation of database pool design. They are
different
in many ways (one of them - threads actually do something themselves, while
database connections only have operations performed on them by those who
request them.)

Again - a pencil and a piece of paper, with little drawing of who does what
might help you. The line in a super-market analogy can work fairly well,
if you map
your objects properly.

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com