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 Fri, 15 Feb 2008 13:45:30 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:

  === Identifying session data changes ===
- /!\ '''The following paragraphs are still under construction. More details can be found
at [https://issues.apache.org/jira/browse/DERBY-3192 DERBY-3192].''' /!\
+ Given that the proposed solution does not use callbacks, it must be possible to compare
the last piggy-backed session data values to those returned from the current embedded connection.
This means that there must be some way of storing the last piggy-backed values in the !NetworkServer
layer. This simple idea is complicated by a number of factors.
+ The values stored within the !NetworkServer need to be initialized to values which lets
them be compared to values from the current embedded connection, even if no piggy-backing
has happened yet. It may seem reasonable to use each session attribute's default value for
this, but doing so would mean that the initially stored values would compare equal to those
in the embedded connection until until an actual change was made. As explained in the [#CLIENT
client section] further down, the client starts with an empty cache, so that if no piggy-backing
has happened yet, the client falls back to sending queries as before. That would, in turn,
mean that any request for a session data attribute which happens ''before'' the client has
changed it from its default value, will result in a query being sent. And since relying on
the defaults is common, this would largely defeat the purpose of session data caching. In
the proposed patch this is remedied by initializing the stored values to
  a special value which is different from anything that can be returned from the embedded
connection. The actual implementation keeps the stored session attribute values in an object
and lets null function as the special value.
- 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`.

- Complications
- conn == null
- conn changed
- conn is closed
+ An alternative solution would have been to let the client initialize its cache to the default
values, but this would introduce a brittle dependency between the the client and the server
code that would be hard to enforce and detect. The client would also be forced to trust (based
on the version information about the server) that it actually will piggy-back changes, whereas
with the proposed approach the client can be defensive and assume that it needs to use queries
to get session data until it actually sees session data arrive from the server.
+ The comparison also needs to consider the state of the current embedded connection. The
following special conditions are equivalent to a comparison that evaluates to true, so no
piggy-backing should be done when:
+  * The current connection is null. This is typically the case for messages being exchanged
prior to a connection being created. If the stored session data is also null, this is ok,
otherwise it is an error condition.
+  * The current connection is closed. In this case no meaningful comparison can be made,
and the stored session data should be dropped.
+  * The current connection is different from the connection used to obtain the stored session
data. This can happen for XA transactions and implies that the stored session data should
be dropped (See [#XA XA section] below).
  === Encoding and decoding session data ===
@@ -135, +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 
@@ -142, +147 @@

  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.  
+ [[Anchor(XA)]]
- == Handling XA Transactions ==
+ == 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

View raw message