Java Enterprise Best Practices

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 ...