POJO Handling in J2EE environment

Case 1. Multiple threads simultaneously accessing one object instance.

Prerequisite: The object is statelss. (The object may have its own internal state, but does not maintain caller specific states.)

Example 1:
For POJO service facade implemented by Singleton, there is only one object instance of the facade class. For each user request, container will dispatch it to a thread picked from a thread pool. These threads will access this facade object instance concurrently. (Needs to be confirmed in WPS environment).

Example 2:
The default (MultiThreaded) mode of Servlet.

Case 2. Mutiple class instances to serve client requests.
Prerequistie: The object is stateful. And it is expensive to syncronize method access.

Example 1:
In SCM Sorter, since InterestLevelComparator is stateful object (to maintain cookie values), a new object instance is created per user request.

Example 2:
SingleThreaded model of Servlet. Servlet container may create multiple instances of the servlet class to serve multiple requests simultaneously.

Case 3. Partial/Whole Synchronization.
Prerequisite: The object is stateful. And it is expensive to create object instance per user request.

* Local variables: Each thread gets its own copy of the local variables, and changes made to these variables do not affect the copies of the local variables of other threads.
* Instance variables: there is only one copy of the instance variables per instance of the servlet, and all of the threads share this copy.
* Class variable: only one copy of a class variable exists across all the instances of the object
belonging to the class for which it is declared. Not surprisingly, just like instance variables, class
variables are not thread safe. In fact, class variables are unsafe even for the singlethreaded
model, because multiple threads may access the same class variable from different
servlet instances. Class variables are used to store “read-only,” or constant, data. Such data is
usually hard-coded in the class.