Is dropping in the pooling code from PoolMan
(http://sourceforge.net/projects/poolman/) something that would make sense
or are you going to implement your own?
rjsjr
> -----Original Message-----
> From: pgsql-jdbc-owner@postgresql.org
> [mailto:pgsql-jdbc-owner@postgresql.org]On Behalf Of Dave Cramer
> Sent: Friday, June 14, 2002 12:30 PM
> To: Johan Svensson
> Cc: Tom Lane; pgsql-jdbc@postgresql.org
> Subject: Re: [JDBC] Problem with JTA/JTS
>
>
> Johan,
>
> Ok, I will try to incrementally patch this so that it at least pools
> connections.
>
> Dave
> On Fri, 2002-06-14 at 12:44, Johan Svensson wrote:
> > On Fri, 2002-06-14 at 17:07, Dave Cramer wrote:
> > > Tom,
> > >
> > > I'm embarassed to say this but looking at the code it appears that the
> > > backend connection isn't really closed at all. I think putting in a
> > > Pooled Connection will help this greatly.
> > >
> > > So this probably fails after you get to maxConnections. Is
> that correct
> > > Johan?
> > >
> > > Dave
> >
> > Seems to be the case. When maxConnections are set to 32 I get 32
> > iterations in my test before exception. When I changed maxConnections to
> > 8 I got 8 iterations.
> >
> > I run the Test and just as I get the exception the message "FATAL 1:
> > Sorry, too many clients already" is printed to console. About half a
> > second or so later I get <maxConnection> number of "DEBUG: pq_recvbuf:
> > unexpected EOF on client connection" to console.
> >
> > It looks like a new connection is created for every transaction and when
> > the transaction is complete the connection isn't released at once but
> > about 1 second later.
> >
> > As you say, pooling connections would probably do the trick.
> >
> > /Johan
> >
> >
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>