You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org> on 2006/02/10 17:25:57 UTC
[jira] Commented: (DERBY-822) Client driver: Pre-fetch data on
executeQuery()
[ http://issues.apache.org/jira/browse/DERBY-822?page=comments#action_12365915 ]
Knut Anders Hatlen commented on DERBY-822:
------------------------------------------
Brief status update...
This seems easier than I first thought. In theory, at least... When
the server receives an OPNQRY (Open Query) it is supposed to respond
with an OPNQRYRM (Open Query Reply Message), QRYDSC (Query Answer Set
Description), and optionally (and with some restrictions) QRYDTA
(Query Answer Set Data).
Right now, the server doesn't return QRYDTA in the response to OPNQRY,
but I found this comment in DRDAConnThread.processCommands():
writeQRYDSC(stmt, false);
// We could send QRYDTA here if there's no LOB data
// in the result set, and if we are using LMTBLKPRC, as
// allowed by drda spec, as an option.
I am not convinced that the comment about LMTBLKPRC is correct, I
think it is also allowed for FIXROWPRC. Will look more into that.
Anyway, I have enabled sending of QRYDTA for LMTBLKPRC and that seems
to work for some simple tests I have run. A lot of failures in
derbynetmats and derbynetclientmats, though. Many of the failures are
caused by changes in the output from SYSCS_GET_RUNTIMESTATISTICS()
(pretty huge diffs). Will have to look more at the failures to see
which ones are real failures.
So far, I haven't had to make any changes on the client side.
> 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 Client, Network Server, Performance
> Versions: 10.2.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Fix For: 10.2.0.0
>
> 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
Re: [jira] Commented: (DERBY-822) Client driver: Pre-fetch data on
executeQuery()
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Kathey Marsden <km...@sbcglobal.net> writes:
> Knut Anders Hatlen wrote:
>
>>Bryan Pendleton <bp...@amberpoint.com> writes:
>>
>>
>>
>>>>I am not convinced that the comment about LMTBLKPRC is correct, I
>>>>think it is also allowed for FIXROWPRC. Will look more into that.
>>>>
>>>>
>>>I think so, too, although there are a number of restrictions in the
>>>fixed row query protocol case. From page 126 of DRDA V.1:
>>>
>>> For the fixed row query protocol, the qryrowset is a parameter on
>>> the OPNQRY command that allows the requester to specify the return
>>> of a rowset with the OPNQRYRM. This parameter applies only to
>>> scrollable, non-sensitive dynamic, non-rowset cursors (QRYATTSCR
>>> is TRUE, QRYATTSNS is not QRYSNSDYN, QRYATTSET is FALSE). For these
>>> cursors, qryrowset specifies that a DRDA rowset is to be returned
>>> with the OPNQRYRM (see Appendix B (on page 655) for more information
>>> about DRDA rowsets). For all other cursors, the parameter is ignored
>>> and no data is returned with the OPNQRYRM.
>>>
>>>Note that not only are there restrictions, but it also seems that
>>>the client has to request this rowset. We can't just send it
>>>automatically when the restrictions are met unless the client also
>>>sets qryrowset.
>>>
>>>
>>
>>I think you are right, Bryan. The Query Data Transfer Protocol Rules
>>(DRDA Vol 1, p. 441) specify this in greater detail.
>>
>>One thing that puzzles me is that the network server has no code for
>>returning QRYDTA in OPNQRYRM when the protocol is FIXROWPRC. The way I
>>read the spec, the server is required to return QRYDTA in FIXROWPRC
>>when qryrowset is non-zero (and there are no LOBs, and the cursor
>>doesn't support multi-row fetch). Does anyone know why it never sends
>>QRYDTA with OPNQRYRM?
>>
> Is there a case where client sends a request with a non-zero qryrowset
> that would necessitate that the QRYDTA be sent with the OPNQRYRM?
I guess not, since we would have noticed that it failed... :)
> I am guessing at the time of implementation JCC was not sending
> qryrowset at all and the support is not there, simply because no one
> has added it yet. In general, there are many pieces of the protocol
> that are missing because the existing clients don't need it and because
> the spec is biggish. If we need it we should add it (with sensitivity
> to older clients of course).
We probably don't need it yet. I think I'll just add support for the
optional QRYDTA in the limited block protocol this time, and then
someone might add what's needed for the fixed row protocol later.
--
Knut Anders
Re: [jira] Commented: (DERBY-822) Client driver: Pre-fetch data on
executeQuery()
Posted by Kathey Marsden <km...@sbcglobal.net>.
Knut Anders Hatlen wrote:
>Bryan Pendleton <bp...@amberpoint.com> writes:
>
>
>
>>>I am not convinced that the comment about LMTBLKPRC is correct, I
>>>think it is also allowed for FIXROWPRC. Will look more into that.
>>>
>>>
>>I think so, too, although there are a number of restrictions in the
>>fixed row query protocol case. From page 126 of DRDA V.1:
>>
>> For the fixed row query protocol, the qryrowset is a parameter on
>> the OPNQRY command that allows the requester to specify the return
>> of a rowset with the OPNQRYRM. This parameter applies only to
>> scrollable, non-sensitive dynamic, non-rowset cursors (QRYATTSCR
>> is TRUE, QRYATTSNS is not QRYSNSDYN, QRYATTSET is FALSE). For these
>> cursors, qryrowset specifies that a DRDA rowset is to be returned
>> with the OPNQRYRM (see Appendix B (on page 655) for more information
>> about DRDA rowsets). For all other cursors, the parameter is ignored
>> and no data is returned with the OPNQRYRM.
>>
>>Note that not only are there restrictions, but it also seems that
>>the client has to request this rowset. We can't just send it
>>automatically when the restrictions are met unless the client also
>>sets qryrowset.
>>
>>
>
>I think you are right, Bryan. The Query Data Transfer Protocol Rules
>(DRDA Vol 1, p. 441) specify this in greater detail.
>
>One thing that puzzles me is that the network server has no code for
>returning QRYDTA in OPNQRYRM when the protocol is FIXROWPRC. The way I
>read the spec, the server is required to return QRYDTA in FIXROWPRC
>when qryrowset is non-zero (and there are no LOBs, and the cursor
>doesn't support multi-row fetch). Does anyone know why it never sends
>QRYDTA with OPNQRYRM?
>
Is there a case where client sends a request with a non-zero qryrowset
that would necessitate that the QRYDTA be sent with the OPNQRYRM?
I am guessing at the time of implementation JCC was not sending
qryrowset at all and the support is not there, simply because no one
has added it yet. In general, there are many pieces of the protocol
that are missing because the existing clients don't need it and because
the spec is biggish. If we need it we should add it (with sensitivity
to older clients of course).
Kathey
Re: [jira] Commented: (DERBY-822) Client driver: Pre-fetch data on
executeQuery()
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Bryan Pendleton <bp...@amberpoint.com> writes:
>> I am not convinced that the comment about LMTBLKPRC is correct, I
>> think it is also allowed for FIXROWPRC. Will look more into that.
>
> I think so, too, although there are a number of restrictions in the
> fixed row query protocol case. From page 126 of DRDA V.1:
>
> For the fixed row query protocol, the qryrowset is a parameter on
> the OPNQRY command that allows the requester to specify the return
> of a rowset with the OPNQRYRM. This parameter applies only to
> scrollable, non-sensitive dynamic, non-rowset cursors (QRYATTSCR
> is TRUE, QRYATTSNS is not QRYSNSDYN, QRYATTSET is FALSE). For these
> cursors, qryrowset specifies that a DRDA rowset is to be returned
> with the OPNQRYRM (see Appendix B (on page 655) for more information
> about DRDA rowsets). For all other cursors, the parameter is ignored
> and no data is returned with the OPNQRYRM.
>
> Note that not only are there restrictions, but it also seems that
> the client has to request this rowset. We can't just send it
> automatically when the restrictions are met unless the client also
> sets qryrowset.
I think you are right, Bryan. The Query Data Transfer Protocol Rules
(DRDA Vol 1, p. 441) specify this in greater detail.
One thing that puzzles me is that the network server has no code for
returning QRYDTA in OPNQRYRM when the protocol is FIXROWPRC. The way I
read the spec, the server is required to return QRYDTA in FIXROWPRC
when qryrowset is non-zero (and there are no LOBs, and the cursor
doesn't support multi-row fetch). Does anyone know why it never sends
QRYDTA with OPNQRYRM? Could it be that FIXROWPRC is used only when
there are LOB columns? And does anybody know how Derby decides whether
FIXROWPRC or LMTBLKPRC should be used?
--
Knut Anders
Re: [jira] Commented: (DERBY-822) Client driver: Pre-fetch data on
executeQuery()
Posted by Bryan Pendleton <bp...@amberpoint.com>.
> I am not convinced that the comment about LMTBLKPRC is correct, I
> think it is also allowed for FIXROWPRC. Will look more into that.
I think so, too, although there are a number of restrictions in the
fixed row query protocol case. From page 126 of DRDA V.1:
For the fixed row query protocol, the qryrowset is a parameter on
the OPNQRY command that allows the requester to specify the return
of a rowset with the OPNQRYRM. This parameter applies only to
scrollable, non-sensitive dynamic, non-rowset cursors (QRYATTSCR
is TRUE, QRYATTSNS is not QRYSNSDYN, QRYATTSET is FALSE). For these
cursors, qryrowset specifies that a DRDA rowset is to be returned
with the OPNQRYRM (see Appendix B (on page 655) for more information
about DRDA rowsets). For all other cursors, the parameter is ignored
and no data is returned with the OPNQRYRM.
Note that not only are there restrictions, but it also seems that
the client has to request this rowset. We can't just send it
automatically when the restrictions are met unless the client also
sets qryrowset.
thanks,
bryan