Factors that affect blocking for DRDA^®

 

A very important performance factor is whether blocking occurs when data is transferred between the application requester (AR) and the application server (AS). A group of rows transmitted as a block of data requires much less communications overhead than the same data sent one row at a time.

One way to control blocking when connected to another System i™ platform is to use the SQL multiple-row INSERT and multiple-row FETCH statements. The multiple-row FETCH forces the blocking of the number of rows specified in the FOR n ROWS clause, unless a hard error or end of data is encountered. The following discussion gives rules for determining if blocking will occur for single-row FETCHs.

Conditions that inhibit the blocking of query data between the AR and the AS are also listed in the following discussion. These conditions do not apply to the use of the multiple-row FETCH statement. Any condition listed under each of the following cases is sufficient to prevent blocking.

• DB2 UDB for iSeries to DB2 UDB for iSeries blocking
  DB2^® UDB for iSeries™ to DB2 UDB for iSeries blocking will not occur under these conditions.

• DB2 UDB for iSeries to non-DB2 UDB for iSeries blocking
  DB2 UDB for iSeries to non-DB2 UDB for iSeries blocking will not occur when one of these conditions is true.

• Non-DB2 UDB for iSeries to DB2 UDB for iSeries blocking
  Non-DB2 UDB for iSeries to DB2 UDB for iSeries blocking will not occur under these conditions.

• Summarization of DRDA blocking rules
  In summary, what these rules (including the notes) say is that in the absence of certain special or unusual conditions, blocking will occur in both of these cases.

 

Parent topic:

Improving distributed relational database performance through the database

 

Related reference

Application does not complete in the expected time