db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-1002) Check that DRDAStatement and DRDAResultSet states are reset when they are re-used
Date Thu, 23 Feb 2006 22:43:56 GMT
"Deepa Remesh (JIRA)" <derby-dev@db.apache.org> writes:

> Deepa Remesh updated DERBY-1002:
> --------------------------------
>
>            type: Bug  (was: Improvement)
>     Fix Version: 10.2.0.0
>       Assign To: Deepa Remesh
>        Priority: Major  (was: Trivial)
>
> I had checked and thought the reset/re-initialization of
> DRDAStatement and DRDAResultSet states is happening correctly in the
> network server code. Hence I had marked this issue to be an
> improvement. I found I was wrong. Sorry about that.
>
> Things I had not understood correctly:
>
> 1) DRDAStatement.rsClose() has this check: if
> (currentDrdaRs.getResultSet() == null) return; I had thought the
> condition will evaluate to true only when DRDAResultSet is
> constructed or after DRDAResultSet.close() has been called. So the
> DRDAResultSet would have been already reset whenever this condition
> is true. This is not correct.
>
> 2) Fields like DRDAResultSet.qryclsimp get set only in OPNQRY
> path. However, writeQRYDTA method used for OPNQRY and EXCSQLSTT are
> same. Hence, in EXCSQLSTT path, it is possible for the query to use
> a left-over qryclsimp. Because of 1) above, if hasdata value is also
> not reset and is false, server will close a query wrongly (even when
> the query should not be closed implicitly and actually has more
> data). One possible error case is - A client which expects a QRYDTA
> as reply to CNTQRY may get a QRYNOPRM from the server.

You're right. qryclsimp should be reset in close(). EXCSQLSTT should
never close queries implicitly and OPNQRY will modify the value of
qryclsimp when setOPNQRYOptions() is called, so Codepoint.QRYCLSIMP_NO
is the correct value.

Would it be a good idea to have a method for initializing variables
that could be called both from the constructor and from close()? It
seems like there are a lot of variables that are not reset in
close(). Most of them are probably reset somewhere else, but the lack
of encapsulation makes it very hard to determine which are reset
correctly and which are not.

-- 
Knut Anders


Mime
View raw message