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 "NetworkServerSessionManagement" by BryanPendleton
Date Wed, 24 May 2006 05:04:10 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 BryanPendleton:

The comment on the change is:
Feedback from Kathey and Dag.

  and this page discusses some of the intricacies of the implementation.
  This page was constructed as part of the work on DERBY-1326, DERBY-1219,
- DERBY-1338, and DERBY-51 (and possibly others?),
+ DERBY-1338, DERBY-1020, and DERBY-51 (and possibly others?),
  although the page is intended to endure after the bugs are fixed, providing
  background information about the implementation.
@@ -99, +99 @@

  {{{Session}}} objects are also closed and discarded when the Network Server
  shuts down or is restarted.
+ === Session closing and DERBY-1020 ===
+ Bug DERBY-1020 is related to the proper handling of exceptions when an exception
+ occurs closing the session especially after the database has been shutdown.
+ There may be some synchronization impact as well because the exceptions that 
+ occur when the database is intentionally shutdown are treated as unexpected 
+ exceptions and it will not go through the normal session shutdown codepath. 
+ Note that DERBY-1020 is the root cause of DERBY-273 (now fixed) and DERBY-803,
+ so there appear to be a number of problems with exceptions that occur during
+ shutdown processing.
  == DRDAConnThread Lifetime ==
  A {{{DRDAConnThread}}} instance is created by the Client Thread when it detects
@@ -143, +156 @@

   * It seems like it might be better to close the master socket first, rather than at the
end, since otherwise there is the chance that new connections will continue to accumulate
during the shutdown processing (though since the Client Thread has been interrupted, no new
work should get started for such connection attempts).
   * Note that we do not close down the embedded Derby engine here. This is the essence of
bug DERBY-51. Basically, the Network Server does not know whether or not it should shut down
the embedded engine, because it is possible to have an application in which there are both
local threads accessing the database directly, and client threads accessing the database over
the network, and just because we are shutting down the Network Server does not necessarily
mean that we no longer want to access the database from the local threads.
   * Lastly, note that in addition to closing each {{{DRDAConnThread}}}, we also call {{{interrupt()}}}
on those threads. This awakens the thread if it was blocked in a {{{wait()}}} call, so that
it can notice the fact that it's been closed.
+ === The implications of interrupting the DRDAConnThread instances ===
+ {{{Thread.interrupt()}}} is a very powerful call, and the fact that we make this call
+ during server shutdown can have unforeseen consequences. Consider, for example,
+ DERBY-1338, in which the {{{Thread.interrupt()}}} call made during server shutdown
+ has the unwanted side effect of interrupting the loading of a class file, causing
+ the {{{DRDAConnThread}}} instance to report a ClassNotFound exception.
+ In general, it seems like it would be preferable to design a protocol in which
+ we do not need to interrupt the daemon thread instances, or, if we do, that we
+ only do so at a point where we are certain that it is safe to interrupt the
+ threads.
  == Network Server restart ==

View raw message