Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: derby-commits@db.apache.org
Date: Mon, 11 Feb 2008 21:20:24 -0000
Message-ID: <20080211212024.25039.552@eos.apache.org>
Subject: [Db-derby Wiki] Update of "Derby3192Writeup" by DyreTjeldvoll

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

------------------------------------------------------------------------------
  connection used by the NetworkServer).
  
  
- 
- 
  = Solutions to the Stale Cache Problem =
  
  One approach to solving the problem would be to scan all activity on
@@ -84, +82 @@

  detect if a new isolation level is being set. This would be able to
  detect changes done in SQL, but not those coming from XA state
  changes, or those happening in stored procedures. A defensive approach
- would be to assume that any stored procedure or XA stat change may
+ would be to assume that any stored procedure or XA state change may
  have changed the isolation level so that a refresh from the server is
- required. This approach seems to limiting to be truly useful (my
+ required. This approach seems to limiting to be truly useful.
- opinion).
  
- The approach that was chosen in this patch was to piggy-back all
+ The approach chosen in DERBY-3192 is to piggy-back all
- changes to the isolation level on the first message going from the
+ changes to the isolation level and the current schema on the first message going from the
- server to client after the change has happened. In the current patch
+ 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 an unknown value which will
+ by allowing the isolation level to be set to a special 'unknown' value which will
- trigger a refresh from the server if no piggy-backed
+ trigger a refresh from the server. That way, if no piggy-backed
- info has reached the client. The defensive approach is used in the XA
- attach/detach situation.
+ 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 ==
@@ -105, +104 @@

  has revealed that better implementation strategies probably exist. This page will be updated
  later.''' /!\
  
+ 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.
- The simplest and least intrusive way of implementing piggy-backing
- would be to create a call-back mechanism that would let
- `EmbedConnection` (through the `EngineConnection` interface) inform its
- `DRDAConnThread` that some information that the client is interested
- in (in this case the isolation level) has changed. The
- `DRDAConnThread` could then append this information to the next
- message being sent to the client. There are two problems with this
- approach:
  
-  1. To my knowledge, DRDA does not allow the server to add replies to a message that do not correspond to a request from the client.
+ 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.
  
+ 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`. 
-  1. The server would need some way of verifying that the client is capable of interpreting the piggy-backed information.
- 
- Another approach is to let the client "poll" the server for cachable
- values that have changed. This can be implemented using the
- request-reply model of DRDA, and the server would only piggy-back
- information to clients that actually request it, so there is no need
- for a hand-shake protocol to find out what the client can handle. (The
- client would still need to make sure that it only sends these requests
- to servers that can handle them, but this is simply a test on the
- servers version number, which is done for things like locators
- already). 
- 
- The disadvantage of this approach is that polling (as always)
- introduces more overhead. Each message going upstream needs to contain
- the poll request, and each message going downstream (to the client)
- needs to contain the (possibly empty) reply. Each time a poll request
- is processed on the server it needs to check if the cachable
- information has changed since last poll. This approach was still
- chosen because the first approach seemed to be
- incompatible with DRDA.
  
  
  == Piggy-backing in DRDA ==