Question regarding handling of bug that network server closes prepared statements if error occurs during OPNQRY

[Kathey Marsden <km...@sbcglobal.net>]

There is a bug in  Network Server that it closes prepared statements if
an error occurs during execution on OPNQRY.
Basically the problem is this code in DRDAConnThread.java
processCommands() which catches any exception that occurs during  OPNQRY
and closes the prepared statement .  (This is new code to 10.2 and does
not exist in 10.1)

catch (SQLException e)
                    {
                        writer.clearDSSesBackToMark(writerMark);
                        try {
                            // Try to cleanup if we hit an error.
                            if (ps != null)
                                ps.close();
                            writeOPNQFLRM(e);
                        }
                        catch (SQLException pse) {}
                        errorInChain(e);
                    }


I have been working on this issue in the context of  DERBY-1047. I
attached a patch to that issue that fixes the problem, but   I have two
problems with DERBY-1047.
1)   The DERBY-1047  title is really  incorrect.  The only time the
problem occurred was if there was an attempt to reexecute the statement
after error.
2) The original repro no longer invokes the issue with the fix for
DERBY-1158, so I need to find a new repro.
    The original  repro had an attempt to use a holdable statement in a
global transaction.  I am having  a hard time getting a new repro for
the issue.  My original attempt was to create a lock timeout but that
does not actually error until CNTQRY.  

I am thinking I should:
1)  file a new issue "Network server closes  prepared statements if
execution error occurs during OPNQRY"  and close DERBY-1047 as Invalid.
2) Go ahead and check in the fix unless someone else can come up with a
new repro. Clearly it is not right that we close the prepared statement
if OPNQRY fails.  I just don't know how to make it fail anymore.

Does that sound ok?

Kathey

Re: Question regarding handling of bug that network server closes prepared statements if error occurs during OPNQRY

[Bryan Pendleton <bp...@amberpoint.com>]

Kathey Marsden wrote:
>> new repro. Clearly it is not right that we close the prepared statement
>> if OPNQRY fails.  I just don't know how to make it fail anymore.

Could it be that the reason this is easier to observe with JCC, than with
the Network Client, is due to deferred prepare? That is, perhaps JCC's
deferred prepare feature means that there is a lot more going on at
open query time, than there is with the Network Client code path. In
Network Client, maybe most of the easy-to-occur errors tend to happen at
prepare time, not at execute query time.

Anyway, I'm glad you found a way to exercise the code path in question.

thanks,

bryan

Re: Question regarding handling of bug that network server closes prepared statements if error occurs during OPNQRY

[Kathey Marsden <km...@sbcglobal.net>]

Kathey Marsden wrote:

>1)  file a new issue "Network server closes  prepared statements if
>execution error occurs during OPNQRY"  and close DERBY-1047 as Invalid.
>2) Go ahead and check in the fix unless someone else can come up with a
>new repro. Clearly it is not right that we close the prepared statement
>if OPNQRY fails.  I just don't know how to make it fail anymore.
>
>  
>
Actually, running derbyall I see that jdbcapi/setTranasactionIsolation
test  has a case that hits the "statement already closed error " with
JCC.  It does not appear with the patch and brings the jcc output closer
to embedded/client.
So, I can  just go with that for a test case.

Kathey