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 Thu, 14 Feb 2008 12:46:32 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

------------------------------------------------------------------------------
  have changed the isolation level so that a refresh from the server is
  required. This approach seems to limiting to be truly useful.
  
- 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. 
  
  == 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].''' /!\
  
+ The discussion at [https://issues.apache.org/jira/browse/DERBY-3192 DERBY-3192] showed that
it is possible to add new ''product-specific'' code points which can be used to implement
piggy-backing. This idea is the basis for the `derby-3192-mark2.*.diff` series of patches,
and is described in the following paragraphs.
+ 
+ 
  === 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.
  
  === 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).
+ Complications
+ conn == null
+ conn changed
+ conn is closed
+ 
  
  === Encoding and decoding session data ===
  
+ The goal 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. The following DRDA commands
appears to be able to modify either the isolation level or the current schema, (the server
was equipped with an ASSERT to verify that session data was not modified by other commands):
+ 
+  * EXCSQLIMM
+  * EXCSQLSTT
+  * OPNQRY
+  * 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. 
+ 
+ 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. 
+ 
+ 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:
+ 
+ || '''Code point''' || '''Code point name''' || '''Payload''' ||
+ || 0xC000           || PBSD                  || One or both of PBSD_ISO and PBSD_SCHEMA
||
+ || 0xC001           || PBSD_ISO              || 1 byte, JDBC isolation level ||
+ || 0xC002           || PBSD_SCHEMA           || UTF-8 encoded string, current schema name
||
+ 
  
  === Maintaining cached session data on the client side ===
-  
+ 
+ Initial value 
+ 
+ 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.  
+ 
  
  == Handling XA Transactions ==
  

Mime
View raw message