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.
Thursday, May 11, 2006
Pojo-based Middle Tier Vs. Thread Safe
A post popped up on the Spring mailing list regarding thread safety. The poster wanted to know if the "singleton, POJO-based service model" Spring recommends for a typical webapp is actually a good thing concurrency and scalability wise.
In my consulting work, I've been asked exactly this same question: When you're talking about a web-tier interfacing with a co-located, POJO-based middle tier, what does it mean to be "thread safe"? When do you have to worry about concurrency?
A guiding principle to heed is "never share caller specific (aka request specific) state between threads". Local variables are one way of achieving this (for example, declared within a thread-safe method of a request handler or servlet). ThreadLocals are another. A third is use of stateless service collaborators, the subject of this blog.
When you're talking about a traditional stateless service object--which is typically what these POJOs business facades are--a single instance typically serves all client requests. While such a singleton service may have its own internal state, it doesn't manage caller-specific state. Everything it needs from callers it gets within a caller's local thread of execution via method parameters. In addition, the internal collaborators these shared services often deal with: data sources, caches, transaction managers, or other resources, are already thread safe themselves (or they sure as heck better be!) :-)
Hence, there is no need to worry about synchronization within your service facades unless you manage shared read/write state yourself (an exceptional case in my experience). There is also no value in service instance pooling: a singleton stateless service object can serve all clients, and can easily be scaled across a cluster. There is value in resource pooling, but that's typically already handled transparently for you, by good infrastructure providers (like jakarta common's dbcp, for database connection pooling).
So, in summary, there is often no need to create a new, local service object per request (e.g a one shot "command object") unless there is caller specific state that object needs to be initialized with (in cases where the command pattern makes sense.) In the case where the per-request Command pattern does make sense, you can easily implement this "one-shot command" in Spring by declaring a prototype bean definition, retrieving a new instance instantiated, configured, and wired by the Spring IoC container on a per-request basis.
Trackback URL: http://jroller.com/trackback/kdonald/Weblog/when_shared_state_is_thread
How to make a program thread-safe
When multiple threads execute a single instance of a program and therefore share memory, multiple threads could possibly be attempting to read and write to the same place in memory.If we have a multithreaded program, we will have multiple threads processing the same instance.What happens when Thread-A examines instance variable x? Notice how Thread-B has just incremented instance variable x. The problem here is Thread-A has written to the instance variable x and is not expecting that value to change unless Thread-A explicitly does so. Unfortunately Thread-B is thinking the same thing regarding itself; the only problem is they share the same variable.
First method to make a program threadsafe: Avoidance
To ensure we have our own unique variable instance for each thread, we simply move the declaration of the variable from within the class to within the method using it. We have now changed our variable from an instance variable to a local variable. The difference is that, for each call to the method, a new variable is created; therefore, each thread has its own variable. Before, when the variable was an instance variable, the variable was shared for all threads processing that class instance. The following thread-safe code has a subtle, yet important, difference. This only applies to primitives. When it comes to actual Objects, the local variable does not make the program thread-safe since the variable just holding the reference to the unique object.
Second defense:Partial synchronization
Thread synchronization is an important technique to know, but not one you want to throw at a solution unless required. Anytime you synchronize blocks of code, you introduce bottlenecks into your system. When you synchronize a code block, you tell the JVM that only one thread may be within this synchronized block of code at a given moment. If we run a multithreaded application and a thread runs into a synchronized code block being executed by another thread, the second thread must wait until the first thread exits that block.
It is important to accurately identify which code block truly needs to be synchronized and to synchronize as little as possible. In our example, we assume that making our instance variable a local variable is not an option.
Third Defence: Whole synchronization
Here u should implement an interface which make the whole class a thread safe on or synchronized
First method to make a program threadsafe: Avoidance
To ensure we have our own unique variable instance for each thread, we simply move the declaration of the variable from within the class to within the method using it. We have now changed our variable from an instance variable to a local variable. The difference is that, for each call to the method, a new variable is created; therefore, each thread has its own variable. Before, when the variable was an instance variable, the variable was shared for all threads processing that class instance. The following thread-safe code has a subtle, yet important, difference. This only applies to primitives. When it comes to actual Objects, the local variable does not make the program thread-safe since the variable just holding the reference to the unique object.
Second defense:Partial synchronization
Thread synchronization is an important technique to know, but not one you want to throw at a solution unless required. Anytime you synchronize blocks of code, you introduce bottlenecks into your system. When you synchronize a code block, you tell the JVM that only one thread may be within this synchronized block of code at a given moment. If we run a multithreaded application and a thread runs into a synchronized code block being executed by another thread, the second thread must wait until the first thread exits that block.
It is important to accurately identify which code block truly needs to be synchronized and to synchronize as little as possible. In our example, we assume that making our instance variable a local variable is not an option.
Third Defence: Whole synchronization
Here u should implement an interface which make the whole class a thread safe on or synchronized
Subscribe to:
Posts (Atom)