Java Reference
In-Depth Information
Timer. Timer is a convenience mechanism for scheduling tasks to run at a later time,
either once or periodically. The introduction of a Timer can complicate an otherwise
sequential program, because TimerTask s are executed in a thread managed by the
Timer , not the application. If a TimerTask accesses data that is also accessed by other
application threads, then not only must the TimerTask do so in a thread-safe manner,
but so must any other classes that access that data . Often the easiest way to achieve this
is to ensure that objects accessed by the TimerTask are themselves thread-safe, thus
encapsulating the thread safety within the shared objects.
Servlets and JavaServer Pages (JSPs). The servlets framework is designed to handle
all the infrastructure of deploying a web application and dispatching requests from re-
mote HTTP clients. A request arriving at the server is dispatched, perhaps through a
chain of filters, to the appropriate servlet or JSP. Each servlet represents a component of
application logic, and in high-volume web sites, multiple clients may require the services
of the same servlet at once. The servlets specification requires that a servlet be prepared
to be called simultaneously from multiple threads. In other words, servlets need to be
thread-safe.
Even if you could guarantee that a servlet was only called from one thread at a time, you
would still have to pay attention to thread safety when building a web application. Servlets
often access state information shared with other servlets, such as application-scoped objects
(those stored in the ServletContext ) or session-scoped objects (those stored in the per-
client HttpSession ). When a servlet accesses objects shared across servlets or requests, it
must coordinate access to these objects properly, since multiple requests could be accessing
them simultaneously from separate threads. Servlets and JSPs, as well as servlet filters and
objects stored in scoped containers like ServletContext and HttpSession , simply
have to be thread-safe.
Remote Method Invocation. RMI lets you invoke methods on objects running in another
JVM. When you call a remote method with RMI, the method arguments are packaged (mar-
shaled) into a byte stream and shipped over the network to the remote JVM, where they are
unpacked (unmarshaled) and passed to the remote method.
When the RMI code calls your remote object, in what thread does that call happen? You don't
know, but it's definitely not in a thread you created—your object gets called in a thread man-
aged by RMI. How many threads does RMI create? Could the same remote method on the
same remote object be called simultaneously in multiple RMI threads? [4]
Search WWH ::




Custom Search