From derby-commits-return-9424-apmail-db-derby-commits-archive=db.apache.org@db.apache.org Fri Feb 15 16:50:33 2008 Return-Path: Delivered-To: apmail-db-derby-commits-archive@www.apache.org Received: (qmail 54034 invoked from network); 15 Feb 2008 16:50:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 Feb 2008 16:50:33 -0000 Received: (qmail 37490 invoked by uid 500); 15 Feb 2008 16:50:27 -0000 Delivered-To: apmail-db-derby-commits-archive@db.apache.org Received: (qmail 37460 invoked by uid 500); 15 Feb 2008 16:50:27 -0000 Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: "Derby Development" List-Id: Delivered-To: mailing list derby-commits@db.apache.org Received: (qmail 37449 invoked by uid 99); 15 Feb 2008 16:50:27 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Feb 2008 08:50:27 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.130] (HELO eos.apache.org) (140.211.11.130) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Feb 2008 16:50:04 +0000 Received: from eos.apache.org (localhost [127.0.0.1]) by eos.apache.org (Postfix) with ESMTP id 7F564D2DD for ; Fri, 15 Feb 2008 16:50:12 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki To: derby-commits@db.apache.org Date: Fri, 15 Feb 2008 16:50:12 -0000 Message-ID: <20080215165012.2342.79970@eos.apache.org> Subject: [Db-derby Wiki] Update of "Derby3192Writeup" by DyreTjeldvoll X-Virus-Checked: Checked by ClamAV on apache.org 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;