db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: [jira] Updated: (DERBY-614) Execution failed because of a Distributed Protocol Error
Date Wed, 23 Nov 2005 14:32:21 GMT
Bryan Pendleton (JIRA) wrote:

>     [ http://issues.apache.org/jira/browse/DERBY-614?page=all ]
>
>Bryan Pendleton updated DERBY-614:
>----------------------------------
>
>    Attachment: spec.html
>
>  
>
>Add a new private member variable: | // splitQRYDTA is normally null.
If it is non-null,

I think that this will have to be in DRDAResultSet for the case where
there are multiple resultsets. 
Then the getter/setter in DRDAStatement can call
currentDrdaRs.getSplitQRYDTA. 

|>The current implementation attempts to loop, retrying the calls to
writeFDODTA until the result set is exhausted, but I think this is
wrong. I >don't really understand why the looping is here, but I suspect
that in practice it never actually was looping more than once.
I think the looping allowed multiple rows to be fetched up to the
qryblksize (32K).   I think that processing could be moved down to the
loop in  writeFDODTA to get the same behavior of prefetching 32k of data
and keep your cleaner implementation. 

Some more detail and complications.
  I think the loop  handles this case in QRYROWSET documentation which 
I think is the general case for network server.
— If QRYROWSET is not specified on the OPNQRY command, then an implicit
rowset is
 returned. The implicit rowset has a size that is defined by DRDA Query
Data Transfer
Protocol rule QP4 and does not include any extra query blocks.

but in fact it looks like the current code will aways prefetch up to 32K
even if qryrowset is set.  Does client send qryrowset  as a rule?









|

|


Mime
View raw message