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 Wed, 27 Feb 2008 18:24:51 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

------------------------------------------------------------------------------
   * CNTQRY
   * SYNCCTL
  
- 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. 
+ The SYNCCTL command is used in conjunction with XA, and the changes caused by this command
must also be piggy-backed.
  
  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. 
  
@@ -148, +148 @@

  [[Anchor(XA)]]
  == XA Transactions ==
  
+ There is really no reason to treat the XA commands differently from other DRDA commands
which modify session data. Piggy-backing has (in the latest version of the patch, after some
gentle nudging by the reviewers) been added to the reply to the SYCNCCTL command. This way
every XA state change which modifies session data also updates the client-side cache. Hence
there is no longer necessary to clear the client cache on each XA state transition (as was
done in earlier versions of the patch).
- 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 ==

Mime
View raw message