Threads 003: Server-Side Strategies

Hi,
Ammendment:

This article may inappropriately suggest that a single threaded server-side
object using LockManager is significantly safer than a corresonding multi-
threaded object.
While the single-threaded, server-side object will contain less pitfalls, it is
not a cure-all. And, I apologize if I have suggested that. For any server-
side objects, whether single-threaded or multi-threaded, that access a shared
resource, such as the LockManager, must be appropriately coded as if
they were multi-threaded for that particular, critical part of the code.

***********************************
Threads003: Server-Side Strategies
***********************************
Please see this link
http://www.coderanch.com/t/185138/java-developer-SCJD/certification/NX-Exam-Locking-Issues
where the two basic approaches
1. the Multi-Threaded One Group, and
2. the Single-Threaded N Group
are defined.
Overview
--------
This article gives a broad comparison of the different RMI-based server-side
strategies, and gives my current opinion as to which is the best, both with
respect to the using of resources and with respect to avoiding multi-threaded
coding where it can be avoided.
Remote Objects
--------------
Depending on your design, the major remote object which the client uses to
communicate with the database is either called something like DataImpl or
MyServerImpl. For simplicity in this article, we will call this object
DataImpl, but either form of object might be used if your assignment does not
expressively forbid one or othe other.
Server-Side Strategies
----------------------
The first item in the following list I thought of this morning, and this
motivates the writing of this article:
These server-side strategies are now listed:

One question which I have asked, and which has not been answered yet (though,
of course it may have been answered in another thread, or in a way which did
not register with me yet), is this:
is RMI a toy? Or is it a serious production-based, networked solution? That
is, how many clients can a normal, server support before the RMI system becomes
too slow?

I. Multi-Threaded One-Instance DataImpl Shell
----------------------------------------------
This is a server-side strategy I thought of this morning, and at this time is
quite probably how I will submit my exam. What I like about it is that if I
were designing a production-based, real-world RMI solution, I would chose this
solution; and, its multi-threaded complexity is low.
This section outlines a production-based solution; however, keep in mind that
I will most probably not implement a production-based solution since it is not
required for the exam; thus, some components of this solution I will not
implement, but the general concept I will most probably implement (or at least
investigate, for I never know what I will actually submit):
Diagram:

Concept: One DataImpl instance exists on the server. It delegates each
business request to a single-threaded new DataWorker; each DataWorker, being
single threaded, is easier to design, code and test, but at the cost that each
new DataWorker temporarily uses up memory. When the DataWorker has carried out
the business method request, it can be garbage collected. The strains on
memory resources is short-lived, because DataWorker's life is short-lived.
A production-based solution might determine in advance the maximum allowable
number of instantiated DataWorker objects that will be allowed to exist on the
server at any given time (since you don't want the server to run out of memory).
This would be set in the server's preferences panel.
A production-based solution, if it already had the maximum number of DataWorker
objects instantiated and working, and another, new request came in, would find
a way to delay carrying out this request until one of the current DataWorker
objects was completed with its job. As it delays the requst, i.e., makes the
incoming thread wait(), it might also determine just how many incoming threads
in total can be made to wait (without exhausting memory or hogging the server's
memory), and then after some limit has been reached, inform the user that the
server is too busy.
A production-based solution might find a way to re-use DataWorker objects, so
you don't have to continually ask for a new one after an old one has carried
out a business method.
Be wary of making DataImpl overly complicated, however, since it is
multi-threaded.

II. Single-threaded N-Instance DataImpl
----------------------------------------

In this design, the Factory supplies the client with a unique, new, server-side
DataImpl which is single-threaded. This is somewhat similar to the first
design outlined in this article with the following difference: each instance
of DataImpl (one per client) continues to exist as long as the client is
connected to the server; for a production-based solution, I would not choose
this design as it could, given a sufficiently large number of users, exhaust
the server's memory. And, the number of RMI connections is unbounded.
Furthermore, another drawback is that each server-side DataImpl object, has a
life-time equal to that of how long each client stays connected, even though
the actual work the client does while connected with respect to needing the
server may be only 1/1000 or 1/10000 or 1/100000 of that time. For instance,
when you use a web site, you spend 1/10 of a second accessing the page from the
server, and you may spend one hour reading the web page.

III. Multi-threaded N-Instance DataImpl
----------------------------------------

"DataImpl_#1" means server-side instance number 1 of DataImpl. "DataImpl_#2"
means the second server-side instance of DataImpl, and so forth.
This is similar to the design given just above, but now each instance of
DataImpl is potentially mult-threaded and serves M clients (it would be
determined what the maximum number of clients one instance can serve efficiently
would be).
This is what happens for the default behavior of a servlet within a servlet
container. Given one servlet class, then based upon the demand for that
servlet, the servlet container decides how many servlet instances will be
created, and how many client-request threads will be multi-threaded through
any given instance.
This was the design I was thinking of implementing until this morning I thought
of the first design outlined in this article.
Of course, here multi-threading issues abound, and it would take non-trivial
skill to implement DataImpl correctly in this multi-threaded environment.
A production version would dynamically instantiate DataImpl instances based
upon server demand, multi-thread them up to a certain maximum based upon
server demand, and destroy DataImpl instances when server demand drops. The
fact that RMI does not do this coding for you, that is, the fact that RMI does
not provide a servlet-like-container for you, may be what separates RMI as a
toy while servlets are considered production-ready paradigms.

IV. Multi-threaded One-Instance DataImpl
-----------------------------------------

Similar to the design given just above, but with heavy demand, would become
unresponsive sooner.

Thanks,
Javini Javono
[ February 14, 2004: Message edited by: Javini Javono ]
[ February 14, 2004: Message edited by: Javini Javono ]