DB Connection Pooling Concerns

[Pascal Davoust <Pa...@wanadoo.fr>]

[snip on DB connection pooling concerns]
>We definitly need a connection pool! ... I've just downloaded
>Turbine to check how we can use it's connection pool. But
>actually I'm not quite sure where to place the connection manager
>object (or whatever it might be called). It has to reside somewhere
>in the HttpServlet class to asure it's not request specific
>and can provide it's service to every sqllib connection query.
>
>Maybe some of the PROs can share our thoughts... ?

First, let's make things clear : I'm not a PRO (whatever a PRO could be)...
;o)

What about using the Factory pattern for your connection manager ?
The idea behind this is to have a single instance of a connection mgr in the
entire system (well, VM in our case). All the servlets (Cocoon is one, right
?) running in the same VM can then access that instance (actually, I know
for sure that, with JServ, _all_ servlets of a single JServ instance run
under the same VM; I don't know about other servlet engines, but I assume
the same way of running), providing the "allocate once, use everywhere" (not
yet TM'ed ? :o) feature you need for you connection pool.
It could be implemented like this :

* Have a class-wide method (well, static method in Java ;o) used as a
factory, which means that you have to call "ConnectionMgr.getInstance()" to
retrieve a reference to a ConnectionMgr
* Have that method allocate such a ConnectionMgr only once, and storing it
for future calls by using a class-wide member (i.e. static member)
(Singleton pattern).

When you've got to use a connection mgr, just call
"ConnectionMgr.getInstance()" in your XSP taglib, and that's all !

What about that ?

                Pascal.

RE: DB Connection Pooling Concerns

[Donald Ball <ba...@webslingerZ.com>]

On Fri, 7 Jul 2000, Torsten Curdt wrote:

> > Guys, guys, thanks for the thoughts but Brian Millett's connection pooling
> > code is already in cvs. just going to do some testing and we'll release
> > 1.7.5 or 1.8.
> > 
> > - donald
> 
> Sweet! .. Do you think the new version with connection pooling will be
> released within -let's say- next week? Sorry for my impatience but
> I'm running out of time...

Probably, but you'd probably be well served to check the current version
out of CVS and test it yourself if it's that important to you.

- donald

RE: DB Connection Pooling Concerns

[Torsten Curdt <tc...@dff.st>]

> Guys, guys, thanks for the thoughts but Brian Millett's connection pooling
> code is already in cvs. just going to do some testing and we'll release
> 1.7.5 or 1.8.
> 
> - donald

Sweet! .. Do you think the new version with connection pooling will be
released within -let's say- next week? Sorry for my impatience but
I'm running out of time...

Thanx
--
Torsten

Re: DB Connection Pooling Concerns

[Donald Ball <ba...@webslingerZ.com>]

On Thu, 6 Jul 2000, Pascal Davoust wrote:

> [snip on DB connection pooling concerns]
> >We definitly need a connection pool! ... I've just downloaded
> >Turbine to check how we can use it's connection pool. But
> >actually I'm not quite sure where to place the connection manager
> >object (or whatever it might be called). It has to reside somewhere
> >in the HttpServlet class to asure it's not request specific
> >and can provide it's service to every sqllib connection query.
> >
> >Maybe some of the PROs can share our thoughts... ?
> 
> First, let's make things clear : I'm not a PRO (whatever a PRO could be)...
> ;o)
> 
> What about using the Factory pattern for your connection manager ?
> The idea behind this is to have a single instance of a connection mgr in the
> entire system (well, VM in our case). All the servlets (Cocoon is one, right
> ?) running in the same VM can then access that instance (actually, I know
> for sure that, with JServ, _all_ servlets of a single JServ instance run
> under the same VM; I don't know about other servlet engines, but I assume
> the same way of running), providing the "allocate once, use everywhere" (not
> yet TM'ed ? :o) feature you need for you connection pool.
> It could be implemented like this :
> 
> * Have a class-wide method (well, static method in Java ;o) used as a
> factory, which means that you have to call "ConnectionMgr.getInstance()" to
> retrieve a reference to a ConnectionMgr
> * Have that method allocate such a ConnectionMgr only once, and storing it
> for future calls by using a class-wide member (i.e. static member)
> (Singleton pattern).
> 
> When you've got to use a connection mgr, just call
> "ConnectionMgr.getInstance()" in your XSP taglib, and that's all !
> 
> What about that ?

Guys, guys, thanks for the thoughts but Brian Millett's connection pooling
code is already in cvs. just going to do some testing and we'll release
1.7.5 or 1.8.

- donald