Here are some things to consider in your answers...
> -----Original Message-----
> From: Mageshkumar Maruthapillai [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, October 04, 1999 1:25 AM
> To: [EMAIL PROTECTED]
> Subject: Very Difficult Servlet Question (Answer not found in Servlet
> books)!!
>
> My senior programmer put me 2 questions w.r.t. threads, servlets and the
> servlet engine.
>
> 1. Suppose unloading or terminating the servlet by calling its destroy()
> method is going to
> cause a threading issue. We have to wait until all the threads
> currently executing in the
> service() methods of the servlet to finish before destroying and
> releasing resources. Lets
> assume that we alsol keep a count of the number of threads in the
> service() methods and
> use a flag as given in the online Java Tutorial.
>
> Question: Even though we do this, how can we prevent new requests from
> entering the
> service() methods even after the destroy() method is
> called. This could mean that
> the servlet is never unloaded???
>
You don't mention the context in which you want to destroy the
servlet. I can think of two reasons; the servlet container is beign shut
down or the servlet container wants to reload a servlet because it noticed
that the servlet's associated classes have changed.
When the container shuts down the first thing it should do is
disconnect itself from its source of requests. For example, if the
container is a stand-alone servlet engine then it should first close all of
its server sockets. If the container is a web server module then it should
unregister itself from the web server.
If the servlet is merely being reloaded then you should start a
separate thread that waits for all service methods to finish executing and
then destroys the servlet. Meanwhile, in the main thread, you load a new
servlet and direct incoming requests to the new servlet instance. If you
really want to be fancy then you'll cache incoming requests and wait to load
the new servlet instance until the thread that's destroying the prevoius
servler instance has finsihed. After the previous servlet has been
destroyed then load a new instance and forward all cached requests to the
new instance. This avoids any bad side-effects where a servlet may depend
on being able to obtain a Singleton system resource.
>
> 2. What sort of new security issues will servlets face when accessing
> resources on the intranet
> for e.g. a file with access rights etc.??
>
Imagine a single servlet container that is running on a web hosting
services web server. This container is to run servlets for all the web
hosting compaines customers. Imagine that Servlet A must have access to
Customer A's files and that Servlet B must have access to Customer B's
files. The access rights to Customer A's files are set so that only
Customer A can access those files. The access rights to Customer B's files
are set so that only Customer B can access those files.
In order for both servlets to be able to access the appropriate file
a single servlet container must be run under a system ID that has access to
both customer's files. This is not a good thing since theoretically
Customer A would have the opportunity to peek at or possibly damage files
belonging to Customer B. To be really secure you should have a servlet
container for each customer that runs in its own process under the
customer's system ID. In the future some containers may use custom
SecurityManagers to create a sandboxes for each customer's servlets.
>
>
>
ted stockwell
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
