Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.
The following page has been changed by DyreTjeldvoll:
http://wiki.apache.org/db-derby/Derby3192Writeup
------------------------------------------------------------------------------
from the PKGNAMCSN instance variable which by itself uses 76 bytes, or
59% of the total overhead:
+
|| DRDA VARIABLE || SIZE (BYTES) ||
|| DSS header || 6 ||
|| EXCSQLSET || 4 ||
@@ -223, +224 @@
|| DRDA VARIABLE || SIZE (BYTES) ||
|| DSS header || 6 ||
- || SQLCARD 65 || ||
+ || SQLCARD || 65 ||
- || SQLSTT 4 + 1 + 4 + (4+1)(strlen) + 1 (15) ||
+ || SQLSTT || 4 + 1 + 4 + (4+1)(strlen) + 1 (15) ||
- || ... || ... ||
- || TOTAL || 71/86 ||
+ || ... || ... ||
+ || TOTAL || 71/86 ||
When no session parameter has changed (the common case) only the 71
bytes of the DSS header and the SQLCARD will be added to the reply. If
@@ -242, +243 @@
Following the example of `setQueryTimeout()`, calls to
`writeSetSpecialRegister()` and `readSetSpecialRegister()` are made
inside `Statement.flowExecute()`. The request is added in the first
- part of the method, prior to calling `...flow()`, and the reply is
+ part of the method, prior to calling `agent_.flow(this)`, and the reply is
read in the latter part of the method, after the blocking call to
- `...flow()` returns.
+ `agent_.flow(this)` returns.
In the case of `setQueryTimeout()`, the request is added to the
beginning of the outgoing message (which is reasonable to ensure that
all the following actions observer the time limit), and the subsequent
- reply is the first received and parsed after `...flow()` returns.
+ reply is the first received and parsed after `agent_.flow(this)` returns.
When polling for changed session data the situation is the exact
opposite; the poll request needs to be the last thing added to the
@@ -261, +262 @@
=== Scrollable Result Sets ===
- Most of the time this works well because call to `...flow()` is
+ Most of the time this works well because call to `agent_.flow(this)` is
followed by a single reply, but for scrollable
result sets this is not the case. If `Statement.isQuery__` is
true and the `Statement.resultSet_' is not null, a call to
@@ -320, +321 @@
suggested fetch size is.
- === Possible Solutions ===
+ == Possible Solutions ==
The initial idea was to handle this by trying to detect this situation
on the server, and not send a session data reply until all calls to
|