Re: Connection pool deadlock

Anil,

You can have multiple result sets on the same connection, as long as you
create different statements.

Why didn't the multiple of 3 thing work?

Dave
On Fri, 2003-02-28 at 05:46, Anil Kumar wrote:
> Hi Dave,
>
> The reason for multiple connections is that the Objects in my
> application contact the database directly for their persisitency
> requirements. And I am not creating any connection object in that
> jsp page directly. Instead I'm making calls to those objects and
> they in-turn contact the database to get the data. This is the
> reason for multiple connections. I think I can reduce the number of
> concurrent connections required while rendering that page but I
> cannot eliminated it completely.
>
> Me too had the idea of keeping the pool size as an integral
> multiple of 3 but didn't work :(
>
>
> --- Dave Cramer <Dave(at)micro-automation(dot)net> wrote:
> > Anil,
> >
> > Other than re-coding which is the real solution; (There is no
> > reason for
> > more than on connection per request) make sure your pool has
> > multiple of
> > 3 connections, ie 9, 12, 15, but not 10.
> >
> > Dave
> > On Fri, 2003-02-28 at 00:25, Anil Kumar wrote:
> > > Hi All,
> > >
> > > I'm facing a problem with connection pooling. I'm using the
> > > pg73jdbc3.jar
> > > with PG 7.2 on RH 7.3.
> > >
> > > This is a Web application running on Tomcat. To render one of
> > its
> > > pages it
> > > requires three concurrent connections to the database. It
> > requests
> > > one
> > > connection after another and return them in the reverse order
> > (the
> > > last
> > > obtained connection is returned first and so on). This creates
> > a
> > > dead-lock
> > > if multiple requests are coming for this particular page. For
> > > example if
> > > the pool size is 10 and if the application is getting 4
> > > simultaneous
> > > requests for this page I found that the connection allocation
> > > happens in
> > > the following way:
> > >
> > > conn 1 -> request 1
> > > conn 2 -> request 2
> > > conn 3 -> request 3
> > > conn 4 -> request 4
> > > conn 5 -> request 1
> > > conn 6 -> request 2
> > > ...
> > > conn 10 -> request 2
> > >
> > > Here no request (or thread) will get enough number of
> > connections
> > > to
> > > complete the request and all requests will go to an indefinite
> > wait
> > > state.
> > > Of course this happens only when the connection requests
> > reaches
> > > the pool
> > > capacity.
> > >
> > > I guess that some of you must have experienced this problem.
> > What
> > > is the
> > > way out (other that re-coding the application to complete the
> > > request with
> > > single connection)?
> > >
> > > best regards
> > > Anil
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Tax Center - forms, calculators, tips, more
> > > http://taxes.yahoo.com/
> > >
> > > ---------------------------(end of
> > broadcast)---------------------------
> > > TIP 5: Have you checked our extensive FAQ?
> > >
> > > http://www.postgresql.org/users-lounge/docs/faq.html
> > --
> > Dave Cramer <Dave(at)micro-automation(dot)net>
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
--
Dave Cramer <Dave(at)micro-automation(dot)net>