From: | Dave Cramer <Dave(at)micro-automation(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Johan Svensson <johan(dot)svensson(at)windh(dot)net>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Problem with JTA/JTS |
Date: | 2002-06-14 15:07:02 |
Message-ID: | 1024067223.1521.278.camel@inspiron.cramers |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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
On Fri, 2002-06-14 at 10:46, Tom Lane wrote:
> Dave Cramer <Dave(at)micro-automation(dot)net> writes:
> > Ok, the problem is that PostgresDataSource does NOT pool connections.
>
> Well, that answers that ...
>
> On reflection though, the behavior Johan reports seems curious. Is it
> really possible that new connections could be launched faster than old
> ones shut down? The backend startup time is not trivial, and he is
> executing a query on each connection too. It's hard to believe that the
> backend shutdown time exceeds startup + query time.
>
> Can you think of any reason why the client-side connection closure might
> not get signaled to the backend immediately? If, say, there were some
> kind of TCP timeout involved, then the report would make a whole lot
> more sense.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Adler | 2002-06-14 15:35:37 | COPY support in pgsql-jdbc driver |
Previous Message | Tom Lane | 2002-06-14 14:46:14 | Re: Problem with JTA/JTS |