[snip]
Are you storing anything in session scope which might cause the function
to be cached?
No -- when the SUBMIT button is pressed, a bean is instantiated, the bean's
properties are set based on the HTML form, and then the bean's "insert"
method is called. The "insert" method gets a connection from Tomcat's
connection pool, uses it to create a PreparedStatement, and then uses the
bean's properties to set the PreparedStatement's parameters. It executes
the statement, and finally closes the PreparedStatement and then the
Connection (in a finally { } block) before leaving the method.
So, nothing's being stored in the session -- the bean, PreparedStatement,
and Connection objects are all created and destroyed/closed in the scope of
the request.
However, it is possible that each request is using the same database
connection, since each request closes the connection it used, returning the
connection to Tomcat's connection pool. Even if the connection is the same,
however, the specific PreparedStatement should have gone away when it was
closed, shouldn't it have? And even if it cached the PreparedStatement,
why/how would it be able to cache Postgres's response to it?
So confused,
Jim
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Paul Thomas
Sent: Friday, April 30, 2004 2:01 PM
To: Jim Steinberger
Cc: pgsql-general @ postgresql . org
Subject: Re: JDBC caching plpgsql function errors?
On 30/04/2004 17:34 Jim Steinberger wrote:
> [snip]
> Anyone have any ideas? I /think/ I worked around this same problem a few
> months ago by restarting the server, but clearly I shouldn't have to do
> that
> every time I modify a function.
Are you storing anything in session scope which might cause the function
to be cached?
--
Paul Thomas
+------------------------------+--------------------------------------------
-+
| Thomas Micro Systems Limited | Software Solutions for
Business |
| Computer Consultants |
http://www.thomas-micro-systems-ltd.co.uk |
+------------------------------+--------------------------------------------
-+
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
