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

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

sergey@total-knowledge.com wrote:
>>> Ok, here is how I understand DB pool related functionlity at this
>>> point(so
>>> far without some details of how pool will work internally):
>>>
>>> DB pool initialized in InitServlet::init() and pointer to it stored in
>>> ServletContext.
>>>
>>>       
>> InitServlet? What is that? (other then that, idea seems to be fine)
>>     
>
> It's a servlet that is used for creating the instance of the pool and
> saving  a pointer to it in ServletContext.
> Here is how it may look like:
>
> void InitServlet::init()
> {
>
>   string numCon = getServletConfig().getInitParameter("num_connections");
>   ServletContext& ctx = getServletConfig().getServletContext();
>   uuDBPool* pool = new uuDBPool(numCon);
>   ctx.setAttribute<uuDBPool*>("uu_pool", pool);
>
> }
>
> Perhaps I'm going to add InitServlet::destroy() to release all resources
> and close all connections in the pool.
>   
How about using UUServlet for that purpose?
>> We will always have a cap. BTW, what happens, if there are no
>> connections available and we reached the cap?
>>     
>
> In this case we'll have to wait for the available connection.
> We may specify timeout in milliseconds for how long the client is willing
> to wait for a connection. I think this value has to be application level
> parameter too and has to be passed to uuDBPool::getConnection() among with
> authentication credentials, server and sessionid.
>   
Well, if it's application-level anyways, you might as well store it in
the pool
itself (like database credentials, max number of connections, etc.)
> So we wait until:
> 1. We get a signal from releaseConnection() that connection returned to
> the pool and available for use.
> 2. If no signal arrived, we wait till timeout elapsed, then return
> null(I'm not sure what we should do in this case). This needed to avoid
> infinite loop imho.
>   
Sounds good.
>>> Connection has to be closed and removed from the pool
>>> 1. At shutdown. We have to loop through all connections in m_connections
>>> list and close them, then clear m_connections list.
>>>
>>>       
>> What happens to connections that were requested by servlets and weren't
>> returned to the pool when shutdown occurs?
>>     
>
> Those unreturned connections have to be closed.
> Perhaps we should have a list for checked in connections too and clear it
> on shutdown the same way as we clear m_connections.
>   
But how will those functions that got hold of connections know that
connections have disappeared from under them. What happens to
transactions that are in progress at that time?
>> That is correct. The question then is, how do you know connection
>> was closed, while it is in the m_connections list.
>>     
>
> Now I'm not sure if it's possible. Maybe sptk' CDatabase has methods to
> check if a connection is opened or closed?
>   
I guess that's a question to Alexey...
>>
>> You could provide some helper functions for those purposes.
>> I am not clear on what kind of help they'd provide though.
>> UUServlet::getDbConnection(HttpSession&) perhaps? Dunno...
>>     
>
> The only problem that I see in having those connection operations in each
> servlet' service() is that we have to get all 4(or 5) parameters from
> request each time.
> Here is how I would do it:
>
> Create EnvironmentSetupServlet and include it in Header.cpp.
> Then retrieve all needed for getConnection(login, password, server,
> sessionid, timeout) from request(login, password, server) from
> HttpSession(sessionid) and from
> getServletConfig()::getInitParameter(timeout).
> Those parameters will be available in each servlet and from design POW the
> code will look OK.
>   
I think you are forgetting about UUServlet again.

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