Don’t Use SingleThreadModel
Now,
onto a servlet feature for which there’s never a
good use: SingleThreadModel.
Here’s my advice: don’t use it.
Ever.
This interface was intended to make life easier for programmers
concerned about thread safety, but the simple fact is that
SingleThreadModel does not help.
It’s an admitted mistake in the Servlet API, and
it’s about as useful as a dud firecracker on the
Fourth of July.
Here’s how the interface works: any servlet
implementing SingleThreadModel receives a special
lifecycle within the server. Instead of allocating one servlet
instance to handle multiple requests (with multiple threads operating
on the servlet simultaneously), the server allocates a pool of
instances (with at most one thread operating on any servlet at a
time). From the outside this looks good, but there’s
actually no benefit.
Imagine a servlet needing access to a unique resource, such as a transactional database connection. That servlet needs to synchronize against the resource regardless of the servlet’s own thread model. There’s no difference if two threads are on the same servlet instance or on different servlet instances; the problem is that two threads are trying to use the connection, and that’s solved only with careful synchronization.
Imagine instead that multiple copies of the resources are available,
but access to any particular one needs to be synchronized.
It’s the same situation. The best approach is not to
use SingleThreadModel, but to manage the resources ...