From: | Dave Cramer <Dave(at)micro-automation(dot)net> |
---|---|
To: | Johan Svensson <johan(dot)svensson(at)windh(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Problem with JTA/JTS |
Date: | 2002-06-14 17:29:37 |
Message-ID: | 1024075778.1521.284.camel@inspiron.cramers |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Adler | 2002-06-14 17:39:38 | Re: COPY support in pgsql-jdbc driver |
Previous Message | Sam Varshavchik | 2002-06-14 16:56:44 | Re: COPY support in pgsql-jdbc driver |