Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43FA0B0F.9050707@apache.org>
Date: Mon, 20 Feb 2006 10:31:43 -0800
From: Daniel John Debrunner <djd@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: derby-dev <derby-dev@db.apache.org>
Subject: DERBY-966 - holdability - dubious code in network server.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


I've think I've found a dubious piece of code that could be the cause of
DERBY-966, holdability issues with XA connections and Derby client.
This is within the server code.

lines 513 DRDAStatement.java

Connection conn = database.getConnection();
if (conn instanceof BrokeredConnection)
   ps = conn.prepareStatement(sqlStmt, scrollType, concurType);
else
  ps = prepareStatementJDBC3(sqlStmt, scrollType, concurType,
        withHoldCursor);


The 'if (conn instanceof BrokeredConnection)' is dubious. For one it
doesn't have comments, so I have to guess what the original coder was
trying to do. (one more plug for code comments :-)

>From the svn log it looks like this is really meant to be logic of the
form, if running under jdk 13 do the first statement, else do the second
statement. The bug is that the instanceof check is not an absolute class
check, it is an instance of check, when we have an XA connection the
connection object will be a BrokeredConnection or BrokeredConnection30.
Since BrokeredConnection30 extends BrokeredConnection both of them are
instances of BrokeredConnection, so the instanceof will always be true
and so it looks like we lose holdability state in JDBC 3.0 and above.

I'm still looking through the code to understand how the holdability is
meant to work in jdk 13 and the network server, any pointers on that
would be helpful.

Dan.