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 (athena.apache.org: local policy)
From: Knut Anders Hatlen <knut.hatlen@oracle.com>
To: "Derby Discussion" <derby-user@db.apache.org>
Cc: philb@tower.ie
Subject: Re: Force condition: ERROR 08000: Connection closed by unknown
 interrupt
References: <1319111986.483.140660988171393@webmail.messagingengine.com>
	<4EA0140B.6070503@oracle.com>
	<1319118590.1287.140660988209881@webmail.messagingengine.com>
Date: Thu, 20 Oct 2011 17:25:26 +0200
In-Reply-To: <1319118590.1287.140660988209881@webmail.messagingengine.com>
	(Phil Bradley's message of "Thu, 20 Oct 2011 14:49:50 +0100")
Message-ID: <x662jj65y1.fsf@oracle.com>
User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain

"Phil Bradley" <philb@tower.ie> writes:

>> 
>> Please bear with me, I do not understand the following paragraph:
>> > At the moment, this doesn't address the problem. Specifically, even
>> > after taking these steps, the exception gets thrown after every database
>> > operation.
>> When I read that sentence, I get the impression that the 08000 exception 
>> is being thrown on every JDBC call. Is that right?
>
> Yes, that's correct. The issue is that I cannot force the 08000
> condition but once it occurs, every JDBC call subsequent to that fails
> until the application is restarted. Note that I've never experienced any
> data corruption due to this, just problems with the connection;
> restarting the application has always resolved it.

Maybe the thread's interrupt flag is still on? Derby doesn't clear the
flag when it detects that it has been interrupted, so if you retry
database operations in the same thread after receiving this exception, I
think you'll continue to see that the operations are being interrupted
until you clear the flag, for example by calling Thread.interrupted().

> There's every possibility that there is a problem with the application
> code; it's certainly a little more convoluted that it should be and I'm
> trying to reduce the complexity bit by bit. For the moment though, my
> issue is not with the 08000 error per se, it's that I have no way to
> verify that the error handling that is invoked in response to the 08000
> actually works. 

Maybe you can get it to fail by manually interrupting the thread before
doing some db operations. The following code fails with a 08000 error on
the rs.next() call in my environment:

Thread.currentThread().interrupt();
Connection c = DriverManager.getConnection("jdbc:derby:memory:db;create=true");
Statement s = c.createStatement();
ResultSet rs = s.executeQuery("select * from sysibm.sysdummy1");
rs.next();

-- 
Knut Anders