Re: Problem with JTA/JTS

Robert,

DataSources pool slightly differently than most pools, one thing is that
the DataSource represents a specific database on a server, but can
return connections for different users. I'll have a look at it, but the
actual pooling isn't really the tough part.

dave
On Fri, 2002-06-14 at 14:56, Robert J. Sanford, Jr. wrote:
> 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
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>