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: <43FA1696.5070409@sbcglobal.net>
Date: Mon, 20 Feb 2006 11:20:54 -0800
From: Kathey Marsden <kmarsdenderby@sbcglobal.net>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: DERBY-966 - holdability - dubious code in network server.
References: <43FA0B0F.9050707@apache.org>
In-Reply-To: <43FA0B0F.9050707@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Daniel John Debrunner wrote:

>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.
>  
>
Yes, I think you are right . Not only dubious but badly broken as
evidenced by DERBY-966 . DERBY-1005, and DERBY-1006.

The wrong assumptions here (if  I recall) were
1) That a BrokeredConnection meant we were in an XA transaction
2) For XA connections we  could rely on the  embedded server's process
of switching to CLOSE_CURSORS_AT_COMMIT to avoid having such logic on
the client.

>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.
>
>  
>
In general the way  it works  for both jdk14 and jdk13 is that the
holdability is sent by the client in the PKGNAMCSN.
This is parsed in  parsePkgidToFindHoldability() to determine the
holdability.   Then statements are prepared using that value in
prepareStatementJDBC3.

For XA all of this is summarly ignored per the code above.  Now it seems
quite transparent that that is wrong, but oddly it seemed to make sense
at the time.

Kathey