Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <70700034.1144608804221.JavaMail.jira@ajax>
Date: Sun, 9 Apr 2006 19:53:24 +0100 (BST)
From: "Bryan Pendleton (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-822) Client driver: Pre-fetch data on
 executeQuery()
In-Reply-To: <1336899976.1137581563986.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DERBY-822?page=comments#action_12373790 ] 

Bryan Pendleton commented on DERBY-822:
---------------------------------------

Hi Knut Anders.

This diff is a lot easier to read now that DERBY-1014 has been separated out. Very nice!

I read through the changes and had a couple questions I wanted to ask:

1) I don't really understand why we have to pass the "opnqry" argument down to writeQRYDTA and writeFDODTA. I read your comments and they make sense at a "detail" level, but I think I'm missing the bigger picture. It seems to me like writeQRYDTA and writeFDODTA should not have to care whether they were called in response to a CNTQRY or in response to a OPNQRY, and when I stare at the detailed changes to writeFDODTA I'm puzzled:
  - when called during processing of an OPNQRY, why would it be wrong to call positionCursor()
  - when called during processing of an OPNQRY, doesn't stmt.getQryrtndta() return false?

I think what I'm trying to suggest is that it seems like it would be cleaner to make positionCursor() and stmt.getQryrtndta() "do the right thing" when called during OPNQRY, rather than passing the flag through, since that seems like it would make the code overall more robust and clear. (That is, the "if" statements in writeFDODTA are already too complex for my taste, so I'm hoping not to add any more conditions to them).

2) I don't understand what's going on with the change to DRDAStatement.java. It seems like there are various configuration settings (qryrowset, blksize, maxblkext, etc.) which are being tracked both in the statement and in the result set, and you're changing things so that when these options are passed in an OPNQRY call, they will now affect not only the particular result set for that query, but also the overall statement?

I think I'm just puzzled by this change. It doesn't seem to be directly related to the other work you're doing, except that it involves OPNQRY processing, and I'm concerned that I don't really understand the implications of setting these various variables on the statement object as opposed to on the result set object.

Can you expand upon the reasoning behind the DRDAStatement change, and also help me understand why we have these variables in both the statement and the result set?


> Client driver: Pre-fetch data on executeQuery()
> -----------------------------------------------
>
>          Key: DERBY-822
>          URL: http://issues.apache.org/jira/browse/DERBY-822
>      Project: Derby
>         Type: Improvement

>   Components: Network Server, Performance
>     Versions: 10.2.0.0
>     Reporter: Knut Anders Hatlen
>     Assignee: Knut Anders Hatlen
>     Priority: Minor
>      Fix For: 10.2.0.0
>  Attachments: DERBY-822-v1.diff, DERBY-822-v1.stat, DERBY-822-v2.diff, DERBY-822-v2.stat
>
> Currently, the client driver does not pre-fetch data when
> executeQuery() is called, but it does on the first call to
> ResultSet.next(). Pre-fetching data on executeQuery() would reduce
> network traffic and improve performance.
> The DRDA protocol supports this. From the description of OPNQRY (open
> query):
>   The qryrowset parameter specifies whether a rowset of rows is to be
>   returned with the command.  This is only honored for non-dynamic
>   scrollable cursors (QRYATTSNS not equal to QRYSNSDYN) and for
>   non-scrollable cursors conforming to the limited block query
>   protocol.  The target server fetches no more than the requested
>   number of rows. It may fetch fewer rows if it is restricted by extra
>   query block limits, or if a fetch operation results in a negative
>   SQLSTATE or an SQLSTATE of 02000.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira