From: | Johan Svensson <johan(dot)svensson(at)windh(dot)net> |
---|---|
To: | Dave Cramer <Dave(at)micro-automation(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 16:44:47 |
Message-ID: | 1024073089.26294.226.camel@voids |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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 | Sam Varshavchik | 2002-06-14 16:56:44 | Re: COPY support in pgsql-jdbc driver |
Previous Message | Michael Adler | 2002-06-14 16:13:41 | Re: COPY support in pgsql-jdbc driver |