Re: Connection pool deadlock - Mailing list pgsql-jdbc

--- Dave Cramer <Dave@micro-automation.net> wrote:
...

> Why didn't the multiple of 3 thing work?

If there are 3 connections left in the pool and 3 concurrent
requests come in each will be provided with one connection and it
will go to wait status when the first thread asks for its second
connection.

   Anil



>
> 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@micro-automation.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@micro-automation.net>
> > >
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - forms, calculators, tips, more
> > http://taxes.yahoo.com/
> --
> Dave Cramer <Dave@micro-automation.net>
>


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/