Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Date: Wed, 05 Mar 2008 12:29:42 +0530
From: Narayanan <V.Narayanan@Sun.COM>
Subject: Re: NPE getting length of Blob
In-reply-to: <47CE29AF.5060106@apache.org>
Sender: V.Narayanan@Sun.COM
To: Derby Discussion <derby-user@db.apache.org>
Message-id: <47CE44DE.7020509@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=UTF-8
Content-transfer-encoding: 7BIT
References: <200803041607.55832.daniel@nuix.com>
 <200803051252.37302.daniel@nuix.com>
 <fa14d5020803041854g6f24f3adqa6a5ee51782fecb1@mail.gmail.com>
 <200803051412.15847.daniel@nuix.com> <47CE29AF.5060106@apache.org>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)

Daniel John Debrunner wrote:
> Daniel Noll wrote:
>> On Wednesday 05 March 2008 13:54:19 Raymond Kroeker wrote:
>>> Hi Daniel,
>>>
>>>     What appears to be happening is that the same connection is being
>>> returned by getConnection2().  Basically the implementation of the 
>>> pool is
>>> not thread safe.
>>
>> I thought reusing the connection was the entire point of connection 
>> pooling.  Correct me if I'm wrong.
>>
>> I can't see how getConnection2() could return the same object to two 
>> separate requestors, given that:
>>   - the method is synchronized
>>   - it only reuses a connection if it's in the recycledConnections stack
>>   - connections can only get into the stack after a connectionClosed 
>> event.
>>
>> Unless Derby is sending connectionClosed before the connection is 
>> actually closed, I don't see how it could happen.
>
> That sounds similar to DERBY-2142 ...
>
> https://issues.apache.org/jira/browse/DERBY-2142
>
> Dan.
https://issues.apache.org/jira/browse/DERBY-3379 for the client. Guess 
this issue is the reason for the failure.
I agree with the analysis by Raymond.

It works for embedded because DERBY-2142 has been fixed for embedded. 
DERBY-3379 has been opened afresh
for client.

Looks like the issue is being actively worked on. Guess we would expect 
a resolution soon.

Thank you for the effort taken to analyze the issue Daniel and Raymond. 
Thanks for the pointer to the JIRA Dan.

Narayanan