6.5.2.1. Tip 1: Local variables are thread-safe

public class HomeServlet extends HttpServlet {
    private Customer currentCust;

    protected void doGet(HttpServletRequest request,
            HttpServletResponse response) throws IOException,
            ServletException {
        HttpSession session = request.getSession(true);
        currentCust = (Customer) session.getAttribute("cust");
        currentCust.setLastAccessedTime(new Date( ));
        ...
    }
}

In this code, the currentCust field is obtained from the HttpSession whenever a client enters the doGet( ) method. Unfortunately, if another thread invokes this method an instant later, the currentCust field will be overwritten before the first thread is complete. In fact, dozens of threads could enter the doGet( ) method at roughly the same time, repeatedly replacing the currentCust reference. This would lead to complete failure of this servlet.

The easy fix is to make currentCust a local variable as follows:

public class HomeServlet extends HttpServlet {
    protected void doGet(HttpServletRequest request,
            HttpServletResponse response) throws IOException,
            ServletException {
        HttpSession session = request.getSession(true);
        Customer currentCust = (Customer) session.getAttribute("cust");
        currentCust.setLastAccessedTime(new Date( ));
        ...
    }
}

This fixes our problem because each thread gets its own copy of local variables in Java. By simply removing the object field and replacing it with a local variable, this particular threading problem is resolved.

6.5.2.2. Tip 2: Immutable objects are thread-safe

Whenever two or more threads make changes to the same object at the same time, a race condition can occur. Consider the following code:

public class Person {
    private String firstName;
    private String lastName;

    public void setName(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }

    ...getter methods omitted
}

If two threads invoke the setName( ) method at roughly the same time, the following scenario can occur:

1. Thread "A" sets the first name to "Bill," but is interrupted by thread "B".

2. Thread "B" sets the first and last names to "George" and "Bush."

3. Thread "A" regains control, and sets the last name to "Clinton."

At this point, the person's name is George Clinton, which is clearly not what was intended. Although you could make the setName( ) method synchronized, you would also have to make any get methods synchronized as well.

public class Person {
    private String firstName;
    private String lastName;

    public Person(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }

    public String getFirstName( ) { return this.firstName; }
    public String getLastName( ) { return this.lastName; }
}

Since instances of the Person class cannot be modified, its methods do not have to be synchronized. This makes the objects fast and allows them to be read by many threads concurrently. The only drawback is that you cannot make changes to these objects once they are constructed. The simple fix is to create a brand new Person object whenever a change needs to be made. This is essentially the approach that java.lang.String takes.

Immutable objects are not always an option but can be a useful technique for many smaller "data helper" classes that seem to pop up in every application.

6.5.2.3. Tip 3: Provide a single point of entry

public class CustomerSource {
    public static synchronized Customer getCustomer(String id) {
        // read the customer from a file, or perhaps
        // from a database...
    }

    public static synchronized Customer createCustomer( ) {
        // create a new customer in the file or database
        // and return it...
    }

    public static synchronized void deleteCustomer(String id) {
        // ...
    }
}

This is just one simple approach that works best on smaller applications. A servlet's doGet( ) or doPost( ) method should utilize the CustomerSource class without any data corruption. If the methods in CustomerSource are slow, however, they will hinder scalability as more and more clients wait for their turn to access the underlying data source.

6.5.2.4. Tip 4: Understand the Templates interface

public class MyServlet extends HttpServlet {
    private Templates homePageStylesheet;

    ...
}

But instances of javax.xml.transform.Transformer are not thread-safe; they should be declared as local variables within the doGet( ) or doPost( ) method:

public class MyServlet extends HttpServlet {
    private Templates homePageStylesheet;

    public void init( ) throws UnavailableException {
        ... create the Templates instance
    }

    protected void doGet( ) {
        Transformer trans = homePageStylesheet.newTransformer( );
        ... use this Transformer instance, a local variable
    }
}