Hi Daniel,
    Which pool/version are you using?  Also how are you configuring the pool?  You want to make sure your library is wrapping the connection  or  if not; is interfacing with the pooled connection/data source object.

Raymond

On Tue, Mar 4, 2008 at 4:36 PM, Daniel Noll <daniel@nuix.com> wrote:
On Tuesday 04 March 2008 22:36:17 Narayanan wrote:
> I have tried getting a blob from a result set and tried the length()
> method on it after the following Scenarios
>
> 1) Closing the connection

The underlying problem must be something to do with Connection reuse.  We
discovered that am.PreparedStatement.parameterMetaData_ was being set to null
in markClosed(), and yet the same PreparedStatement object was being reused
for subsequent blob length queries.  So it would work once and then not for
any subsequent attempts.  Subsequent attempts for the same blob would
probably work because the result is cached elsewhere but attempts for a
different blob would use the same cached, invalid PreparedStatement object.

Here's who's setting it to null:
       at
org.apache.derby.client.am.PreparedStatement.markClosed(PreparedStatement.java:2526);
       at org.apache.derby.client.am.Statement.markClosed(Statement.java:1755)
       at
org.apache.derby.client.am.Connection.markStatementsClosed(Connection.java:879)
       at org.apache.derby.client.am.Connection.markClosed(Connection.java:864)
       at
org.apache.derby.client.am.Connection.markClosedForReuse(Connection.java:872)
       at org.apache.derby.client.am.Connection.closeForReuse(Connection.java:833)
       at
org.apache.derby.client.am.NetConnection.closeForReuse(NetConnection.java:1829)
       at
org.apache.derby.client.am.LogicalConnection.close(LogicalConnection.java:80)

We're calling Connection.close() but it's a connection from a pool, and you're
supposed to close those.

Potential fixes:
 - Don't set things to null during close methods (it's inherently dangerous.)
 - Check if the statement is closed after checking whether it's null
(possibly defeats the purpose of caching the statement for the connection.)

Anyway now that we know roughly where the problem is, some Derby developer
will presumably know better than us how to fix it without breaking anything
else.

Daniel



--
---------------------------------------------------------
Raymond Kroeker