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 Tue, 12 Feb 2008 15:18:39 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

------------------------------------------------------------------------------
  
  In all of theses cases the cached values become stale (different from
  the actual isolation level and current schema in the embedded
- connection used by the NetworkServer).
+ connection used by the !NetworkServer).
  
  
  = Solutions to the Stale Cache Problem =
@@ -88, +88 @@

  
  The approach chosen in DERBY-3192 is to piggy-back all
  changes to the isolation level and the current schema on the first message going from the
+ server to client after the change has been made. To avoid having to change every reply (and
every parsing method in the client) only replies to commands that '''can''' change either
attribute will include the changed values. 
- server to client after the change has been made. To avoid having to change every reply (and
every parsing method in the client) only replies to commands that '''can''' change either
attribute will include the changed values. (In order to make sure that no case was missed
the server was equipped with ASSERTs that check that the session data is not changed by commands
that do not piggy-back).
- 
- 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.
- 
  
  == Implementing Piggy-backing ==
  
  /!\ '''The following paragraphs are still under construction. More details can be found
at [https://issues.apache.org/jira/browse/DERBY-3192 DERBY-3192].''' /!\
  
- === Getting session data from the embedded driver === 
+ === Getting session data from the embedded driver ===
  
  In order for piggy-backing to be reasonably efficient the !NetworkServer needs an efficient
(and preferably) convenient way of obtaining the session data from its `EmbedConnection`,
preferably by providing a `getCurrentSchemaName()` method. It would of course be possible
to implement this by executing `VALUES CURRENT ISOLATION` on the embedded connection, but
this seems like much overhead, especially when considering that this query will have to be
performed whenever the !NetworkServer needs to know if the session data has changed.
  
- An even more efficient approach would be if the NetworkServer could register itself as some
kind of listener with `EmbedConnection` which, in turn, would invoke some kind of callback
which informed the !NetworkServer that session data had been modified. This advantage of this
approach did not seem to justify the added complexity and changes to the embedded driver.
+ An even more efficient approach would be if the !NetworkServer could register itself as
some kind of listener with `EmbedConnection` which, in turn, would invoke some kind of callback
which informed the !NetworkServer that session data had been modified. This advantage of this
approach did not seem to justify the added complexity and changes to the embedded driver.
  
  === Identifying session data changes ===
  Given that we have chosen to poll for changes to the session data in the `EmbedConnection`
each time they may have changed, we also need the ability to store the last
  values sent to the client, and a way to compare those with the current values from `EmbedConnection`.

  
+ (In order to make sure that no case was missed the server was equipped with ASSERTs that
check that the session data is not changed by commands that do not piggy-back).
  
  === Encoding and decoding session data ===
  
+ 
- === Maintaining the cached session data on the client side ===
+ === Maintaining cached session data on the client side ===
   
  
  == Handling 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.
+ 
  == Overhead ==
  
- Piggy-backing will necessarily add some overhead to the replies being sent to the client,
but there is no overhead on the requests from the client to server (unlike in the previous
patch proposal).
+ Piggy-backing will necessarily add some overhead to the replies being sent to the client,
but there is no overhead on the requests from the client to server (unlike in the previous
patch proposal). The exact size of the overhead depends on the data being sent, as shown in
the following table:
  
- === Reply ===
  
- Separate DSS(6) + two cp (8) + pay (1->)
- 
- || '''DRDA VARIABLE''' || '''SIZE''' (BYTES)           ||
+ || '''DRDA VARIABLE''' || '''SIZE''' (BYTES)                  ||
- || DSS (PBSD)          || 6                                  ||
+ || DSS (PBSD)          || 6                                   ||
- ||  PBSD_ISO           || 4 + 1                              ||
+ ||  PBSD_ISO           || 4 + 1                               ||
  ||  PBSD_SCHEMA        || 4 + `bytelen(UTF8(schemaname))`     ||
  || TOTAL               || 11/15 + `bytelen(UTF8(schemaname))` ||
  
@@ -139, +135 @@

  
  == Compatibility ==
  
+ 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;
+         }
+ }}}
+ 
+ On the client side compatibility comes "for free" since the client will never cache session
data unless it has received them through piggy-backing. But to be on the safe side `DatabaseMetaData`
has been extended with predicates for determining if the server supports session data caching
through piggy-backing. This allows the client to ASSERT that the server is piggy-backing changes
before it uses its cached session data.
+ 

Mime
View raw message