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 Sun, 21 May 2006 17:50:41 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:
http://wiki.apache.org/db-derby/NetworkServerSessionManagement

The comment on the change is:
Fix list formatting

------------------------------------------------------------------------------
  
  Conceptually, the {{{RunQueue}}} may be in any of three states at any
  given time:
+  * If there are more {{{Session}}} needing work than there are available  {{{DRDAConnThread}}}
instances, than the {{{RunQueue}}} holds the sessions which are awaiting a thread.
+  * If there are more {{{DRDAConnThread}}} instances than there are {{{Session}}} needing
work, then the idle threads wait on the {{{RunQueue}}} for work to become ready.
+  * If there are exactly as many active {{{Session}}} instances as there are {{{DRDAConnThread}}}
instances, then the {{{RunQueue}}} is empty and inactive.
-  * If there are more {{{Session}}} needing work than there are available
-    {{{DRDAConnThread}}} instances, than the {{{RunQueue}}} holds the sessions
-    which are awaiting a thread.
-  * If there are more {{{DRDAConnThread}}} instances than there are {{{Session}}} 
-    needing work, then the idle threads wait on the {{{RunQueue}}} for work to
-    become ready.
-  * If there are exactly as many active {{{Session}}} instances as there are
-    {{{DRDAConnThread}}} instances, then the {{{RunQueue}}} is empty and inactive.
  
  Thus, depending on the current balance of work-needing-a-thread versus
  threads-needing-work-to-do, the {{{RunQueue}}} at any given instant may be
@@ -141, +136 @@

   * It closes the master socket on which it accepts connections
  
  There are several observations worth making here:
+  * 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.
-  * 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.
  
  == Network Server restart ==
  
@@ -173, +155 @@

   * It then starts up a new instance of the Derby engine.
  
  There are several observations worth making here.
+  * Note that while Network Server shutdown closes every session in the {{{sessionTable}}},
Network Server restart only closes the sessions in the {{{RunQueue}}}.
+  * Note that while Network Server shutdown both {{{closes()}}} and {{{interrupts()}}} each
{{{DRDAConnThread}}} instance, Network Server restart just {{{closes()}}} the threads. This
means that the threads may not become aware that they have been closed until some later time,
when they awaken from whatever {{{wait()}}} call they were blocked in.
+  * Note that Network Server shutdown terminates the Client Thread, while Network Server
restart leaves the Client Thread alone. This means that new {{{Session}}} may be coming in
during the restart processing.
-  * Note that while Network Server shutdown closes every session in the
-    {{{sessionTable}}}, Network Server restart only closes the sessions in the
-    {{{RunQueue}}}.
-  * Note that while Network Server shutdown both {{{closes()}}} and 
-    {{{interrupts()}}}
-    each {{{DRDAConnThread}}} instance, Network Server restart just 
-    {{{closes()}}} the
-    threads. This means that the threads may not become aware that they have
-    been closed until some later time, when they awaken from whatever 
-    {{{wait()}}}
-    call they were blocked in.
-  * Note that Network Server shutdown terminates the Client Thread, while
-    Network Server restart leaves the Client Thread alone. This means that
-    new {{{Session}}} may be coming in during the restart processing.
  
  == Synchronization ==
  
@@ -270, +241 @@

  === Possible ways to simplify/repair the synchronization ===
  
  Here are some ideas I've had about possible changes to the synchronization:
+  * I think that the open-coded logic in {{{ClientThread.java}}} which handles creating new
{{{Session}}} and {{{DRDAConnThread}}} objects should be moved into the {{{NetworkServerImpl}}}
class so that it can be uniformly synchronized with the other logic in that class.
+  * I think that it is confusing to use the {{{runQueue}}} as both a collection object and
as a thread wait queue, and it would be simpler and less error-prone to use two separate objects
for that.
+  * I think that primitive methods like {{{getThreadList()}}} and {{{getFreeThreads()}}}
should be avoided, as they risk exposing too much of the implementation to callers, and allowing
race conditions to be accidentally introduced.
-  * I think that the open-coded logic in {{{ClientThread.java}}} which
-    handles creating new {{{Session}}} and {{{DRDAConnThread}}} objects should
-    be moved into the {{{NetworkServerImpl}}} class so that it can be
-    uniformly synchronized with the other logic in that class.
-  * I think that it is confusing to use the {{{runQueue}}} as both a
-    collection object and as a thread wait queue, and it would be simpler and
-    less error-prone to use two separate objects for that.
-  * I think that primitive methods like {{{getThreadList()}}} and
-    {{{getFreeThreads()}}} should be avoided, as they risk exposing too much
-    of the implementation to callers, and allowing race conditions to be
-    accidentally introduced.
  
  == Changing the Session Management code ==
  

Mime
View raw message