db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "Derby3192Writeup" by DyreTjeldvoll
Date Fri, 15 Feb 2008 16:50:12 GMT
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

The comment on the change is:
 

------------------------------------------------------------------------------
  
  The SYNCCTL command is used in conjunction with XA, so the changes caused by this command
are handled by dropping the cached values in the client, (more about this below), so no data
is currently piggy-backed on the SYNCCTL reply. 
  
- An initial idea was to add the session data to exiting variables(DSSes) in the replies to
these commands. However, closer examination showed that the replies to these commands were
rather different and contained different variables. This meant that modifying existing variables
in the replies would require messy changes to many `write*` methods on the server, and also
to the corresponding `parse*` methods in the client. 
+ An initial idea was to add the session data to existing DSS variables in the replies. However,
closer examination showed that the replies were structured rather differently, contained different
types of DSS variables, and that some of the candidate DSSes were not always included in the
reply. This meant that modifying existing variables to include piggy-backing would require
messy changes to many `write*` methods on the server, and especially to the corresponding
`parse*` methods in the client. 
  
- A cleaner solution appeared to be the use of a separate DSS with its own `writePBSD` and
`parsePBSD` methods that can be added to the end of a reply without depending on other elements
of the reply. To implement the "separate DSS" solution three new code points in the product-specific
range 0xC000-0xffff have been added:
+ Using a separate DSS which can be included without depending on other elements of the reply
seemed to offer a much cleaner solution. Three new code points in the product-specific range
(0xC000-0xffff) have been added to implement the "separate DSS" solution:
  
  || '''Code point''' || '''Code point name''' || '''Payload''' ||
  || 0xC000           || PBSD                  || One or both of PBSD_ISO and PBSD_SCHEMA
||
@@ -137, +137 @@

  || 0xC002           || PBSD_SCHEMA           || UTF-8 encoded string, current schema name
||
  
  
- /!\ '''The following paragraphs are still under construction. More details can be found
at [https://issues.apache.org/jira/browse/DERBY-3192 DERBY-3192].''' /!\
- 
  [[Anchor(CLIENT)]]
  === Maintaining cached session data on the client side ===
  
- Initial value 
+ As mentioned in a previous section, the client starts with and "empty" cache where the cached
session attributes have been initialized to illegal values. Any attempt to access such an
illegal value is trapped an causes the client to fall back to sending a query to the server.
  
- Each time session data arrives piggy-backed with a reply a callback which is defined in
`ConnectionCallbackInterface` and implmented in `am.Connection` is invoked. This callback
updates the cached session attributes in the connection. The callback `completePiggyBackSessionData`
takes an `Object[]` array as argument and each session attribute has its own position in the
array. The array position of attributes that have not changed is given a null value.  
+ Whenever session data arrives piggy-backed on a message, `parsePBSD()` gets called, and
will extract the modified session data and store them in an Object array. Each session data
attribute has its own index in the array. The array slot for attributes that have not changed
is null. It then invokes `ConnectionCallbackIinterface.completePiggyBackSessionData(Object[])`
which is implemented by `am.Connection`. This callback then updates the cached session data
inside the `am.Connection` object.
  
  
  [[Anchor(XA)]]
  == XA Transactions ==
  
- In the current patch this approach is combined with the defensive approach mentioned above
by allowing the isolation level to be set to a special 'unknown' value 
- which will trigger a refresh from the server. That way, if no piggy-backed
- info has been sent, the client will fall back to the old approach. This defensive approach
is used in the XA
- attach/detach situation by letting the client "forget" the cached attribute values (by setting
them back to the special unknown value) when joining/leaving an XA transaction.
+ As mentioned previously, the execution of certain XA operations can modify the current connection
and thereby also the current session data. The proposed patch handles this by letting the
relevant XA state transitions clear the cached session data by setting them back to the illegal
value:
+ 
+ {{{
+      public void setXAState(int state) {
+          xaState_ = state;
+          // Set the cached session attributes back 'unknown' values to force a
+          // synchronization with the server
+          isolation_ = TRANSACTION_UNKNOWN;
+          currentSchemaName_ = null;
+      }
+ }}}
+ 
+ This situation only lasts until the new values get piggy-backed, normally on the first conventional
reply after the XA state change.
+ 
+ There is really no reason to treat the XA commands differently from other DRDA commands
which modify session data. It should (tm) be straight-forward to drop the cache-clearing if
piggy-backing is added to the relevant XA replies. The proposed patch leaves this a future
enhancement, (or alternatively, as an exercise for the reader :) )
+ 
  
  == Overhead ==
  
@@ -173, +183 @@

  
  A change which introduces new product-specific code points needs to consider compatibility
with other drivers (DB2 Universal Driver and IBM's ODBC driver) and older versions of the
!DerbyNetClient driver. Specifically the patch needs to ensure that the new code points only
gets sent to !DerbyNetClient drivers with version 10.4 or higher. This is achieved by testing
both the client type and client version before piggybacking session data:
  
- {{{#!
+ {{{
          if (appRequester.getClientType() != AppRequester.DNC_CLIENT ||
                  !appRequester.greaterThanOrEqualTo(10, 4, 0)) {
              return;

Mime
View raw message