Issues with Integrity of Instance Variables in jsp/servlets

When isThreadSafe is true, then the page does not implement SingleThreadModel, but rather implements the MultiThreadedModel. The default handling for this servlet, as defined by the servlet spec is to create ONE instance of the servlet, which handles all requests. Thus there can be multiple threads going through a JSP/servlet service method. By default a page is threadsafe, that is it does not implement SingleThreadModel but rather the MUltiThreadedModel. So with MultiThreadedModel, session and request are still separate as they are not instance variables and they are just input to the method of the servlet, they don’t belong to the servlet instance. They are sent in when service(httprequest etc…) method is invoked, so they are like local variables. This is not true for instance variables defined in the servlet. Different threads are manipulating a single instance variable.
One way to retain data integrity of local variables is to use the SingleThreadModel(isThreadSafe=”false”).
Normally servlets (or jsps) are kept as a single instance. The service() method is run on separate threads. Now when we explicitly say isThreadSafe =”false” (SingleThreadModel in servlets) the service() method becomes single-threaded, that is the servlet instance is accessed by only one thread at a time. Normally only one instance is still available and this can be a bottleneck for performance. However if you make it single threaded, some servlet engine implementations keep a pool of instances to avoid performance bottlenecks. In such cases, this causes data integrity problems. So the suggestion is don’t make it single threaded – let the isThreadSafe=true which is default.
Then you are assured of having a single instance and multiple threads, but make the instance variables synchronized to manage the conflict between threads. why synchronize? You are trying to keep the integrity of the values stored as instance variables in the servlet. The instance variable is shared by multiple threads. Different threads are manipulating a single instance variable and so you need to synchronize the instance to keep the integrity of instance variable.
This only applies for instance variables outside the service method. Local variables are stored on the stack – each thread has its own stack, they are never shared.

A quick glance at web development design patterns

BUSINESS TIER

1. Business Delegate

A server side layer that exposes the business layer API to the client components.

Advantages:
Promotes reusability of business API -the business service lookup/access is encapsulated.
Reduces dependency of client objects on the server side business layer API implementation.
Adds a layer between presentation and business layers.

2.Value Object/ Data Transfer Object

A serializable object for transferring data over a network

Advantages:
1. Reduces network traffic because the VO is transferred on the server side and frequent client-server calls are reduced. – fewer remote calls
2. Increases response time

3. Session facade

A layer that acts as an entry point into the business layer and manages the workflow of business objects such as session beans/ entity beans and data access objects. It is itself implemented as a session bean.

INTEGRATION TIER

4. Data Access Object

An object that accesses the database separating the business layer from the data access layer. The business layer is shielded from any change in datasource.
The app can dynamically plug into an appropriate datasource on the fly by selecting an appropriate DAO.
Note that the objects of the business and integration tiers reside in the same JVM.
Reduces dependency of business logic on the data access layer.

FRAMEWORK

5. Model View Controller

The Model-View-Controller design pattern is applicable in situations where the same data (Model) is to be presented in different formats (Views), but is to be managed centrally by a single controlling entity (Controller)
Separates the data representation (model) from the data presentation (view)
Separates the application behavior (Controller) from the data presentation (view) and data representation (model)
The presentation (WML/JSP/XML/HTML) may be presented in different format independent of data.
There is a single controller.

BEHAVIORAL PATTERN

6. Front Controller

Provides a common point of entry into the application.
Unifies and streamlines authentication and authorization and dispatches work to appropriate handler components (manages workflow) use-case wise.