[
https://issues.apache.org/jira/browse/DERBY-5328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065106#comment-13065106
]
Kristian Waagan commented on DERBY-5328:
----------------------------------------
A typical way to store data belonging to a specific session, and to retrieve it
later, is to use the session context. We can also pass some of the variables as
arguments, this would require changing the method signatures (while at it, some
other arguments could be removed).
What isn't clear to me, is what kind of underlying state the servlet is
dependent on. Are all executions of the servlet supposed to operate on and
query the same NetworkServerControl, or should there be one instance per
session?
Can the servlet control several network servers, or only one? (I assume one,
since the server is started in the appserver process?)
Finally, can anyone answer whether NetServlet can assume that there will always
be only one instance of it in the web container, or do we have to make sure it
runs properly if the container creates a pool of instances too?
I can't see any reasons why we should make this code able to run in 100's of
concurrent sessions - that doesn't make any sense for the functionality it
provides. However, we should make sure the servlet is properly implemented and
won't fall over or cause side effects if it happens that it is run by
concurrent sessions.
> The private fields of the NetServlet can be changed by multiple threads,
> giving rise to race conditions and corruptions.
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5328
> URL: https://issues.apache.org/jira/browse/DERBY-5328
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.9.0.0
> Reporter: Rick Hillegas
>
> At the beginning of the NetServlet class, there are a number of private
> fields. These fields can be inspected and changed by any thread running
> inside NetServlet.doGet(). Due to the way that app servers dispatch servlet
> requests, this means that multiple threads can be operating inside doGet() at
> the same time, clobbering one another's work. The weirdest instance of this
> is the shared PrintWriter (called "out") which is used to produce the
> response web page sent back by the servlet. Multiple threads all writing to
> the same PrintWriter will create a very bizarre response page. The following
> improvements should be made:
> 1) The "server" field should be set by a synchronized method.
> 2) Every run through doGet() should create its own PrintWriter which is
> passed to other methods. The instance-wide "out" field should be removed.
> 3) Various other fields should be re-coded using the Atomic classes
> introduced by Java 5. These fields include "logStatus" and "traceStatus".
> This solution can be implemented if the community votes to approve the
> sunsetting of JVM 1.4 (currently at the polls).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
