Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 60376 invoked from network); 5 Mar 2008 00:41:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Mar 2008 00:41:22 -0000 Received: (qmail 70686 invoked by uid 500); 5 Mar 2008 00:41:17 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 70645 invoked by uid 500); 5 Mar 2008 00:41:16 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 70634 invoked by uid 99); 5 Mar 2008 00:41:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Mar 2008 16:41:16 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [203.217.22.128] (HELO file1.syd.nuix.com.au) (203.217.22.128) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Mar 2008 00:40:41 +0000 Received: from host68.syd.nuix.com.au (host68.syd.nuix.com.au [192.168.222.68]) by file1.syd.nuix.com.au (Postfix) with ESMTP id C33314A8135 for ; Wed, 5 Mar 2008 11:40:25 +1100 (EST) From: Daniel Noll Organization: Nuix Pty Ltd To: "Derby Discussion" Subject: Re: NPE getting length of Blob Date: Wed, 5 Mar 2008 11:36:42 +1100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200803041607.55832.daniel@nuix.com> <47CD3431.5020205@sun.com> In-Reply-To: <47CD3431.5020205@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803051136.42666.daniel@nuix.com> X-Virus-Checked: Checked by ClamAV on apache.org 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