servlet concurrency

Hi,

I am reading below link.


I have not understood below clearly

Servlet Concurrency

 
By Jakob Jenkov  Connect with me:
Rate article: Share article: Tweet

Last updated: 2014-05-25
A Java servlet container / web server is typically multithreaded. That means, that multiple requests to the same servlet may be executed at the same time. Therefore, you need to take concurrency into consideration when you implement your servlet.

I am not going to describe Java concurrency in great detail here. If you are interested in this topic, read my tutorial on Java Concurrency.

To make sure that a servlet is thread safe, there are a few basic rules of thumb you must follow:

Your servlet service() method should not access any member variables, unless these member variables are thread safe themselves.
Your servlet service() should not reassign member variables, as this may affect other threads executing inside the service() method. If you really, really need to reassign a member variable, make sure this is done inside a synchronized block.
Rule 1 and 2 also counts for static variables.
Local variables are always thread safe. Keep in mind though, that the object a local variable points to, may not be so. If the object was instantiated inside the method, and never escapes, there will be no problem. On the other hand, a local variable pointing to some shared object, may still cause problems. Just because you assign a shared object to a local reference, does not mean that object automatically becomes thread safe.


can you please advise
LVL 7
gudii9Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

gheistCommented:
Please post a link to original tweet and at least 5 lines of YOUR code that is suspectible to not being thread safe.
0
Jim CakalicSenior Developer/ArchitectCommented:
Hi.

For an object to be "thread safe", it must have no shared data structures (data that can be manipulated by more than one thread of execution at a time) or guarantee that shared data structures are either protected from concurrent thread manipulation or are inherently safe (e.g. an immutable collection)

Servlet concurrency describes the typical web server scenario that uses multiple threads within the container to handle multiple incoming requests. Each request is assigned a separate thread of execution, typically from a thread pool. Servlet objects are also typically pooled. A single servlet object instance is created and used to service all incoming requests. This sets up a scenario in which multiple threads are attempting to use the same object to handle simultaneous requests in the web container.

The rules of thumb you quoted are a warning primarily against using class/instance fields in your servlet. Having a field in your servlet could be a conscious design decision or might be accidental. A typical problem example might be that to service a request you need to query and modify a collection of objects from a DataSource. Because you will probably have multiple methods in your implementation, you might decide that instead of passing this collection around to all your methods, you'll make it an instance field so that all the methods have access to it. That's where the thread safety issue lies. Assume a request is received for this servlet and the container gets servlet instance X from the servlet pool, and starts execution of the doGet method on thread A. The servlet creates an empty collection, assigning it to a member field, queries the database, receives a response and begins populating the collection with the result before being interrupted. While interrupted, another request is received and the container against gets servlet instance X from the servlet pool and starts execution of the doGet method on thread B. Only one thread can /really/ be executing at one time so thread A is presently suspended while thread B is executing. On thread B, the servlet code again creates an empty collection, assigning it to a member field, queries the database, but has not yet received a response to the query when it gets interrupted. Thread A resumes execution but because thread B has modified the member field in the meantime, the collection that was populated with the database results is gone and replaced with an empty collection created by thread B. The best case is thread A merely exhibits erroneous behavior, worst case it fails with some kind of exception displayed to the user. This scenario can't happen if the servlet does not have fields or shared objects -- all data for handling a request is constructed and referenced through auto local variables.

Hope that helps.
Jim
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

gudii9Author Commented:
java i feel crux is collection and threading where i get ultimate knowledge about these two topic apart from oracle site? please advise on any good books, vidoes, material
0
gudii9Author Commented:
A typical problem example might be that to service a request you need to query and modify a collection of objects from a DataSource.
when you say datasource you mean database right(not datasource we configure for jdbc connection?)
0
gudii9Author Commented:
Because you will probably have multiple methods in your implementation, you might decide that instead of passing this collection around to all your methods, you'll make it an instance field so that all the methods have access to it.

you means instance field of servlet right?
0
gudii9Author Commented:
The servlet creates an empty collection, assigning it to a member field, queries the database, receives a response and begins populating the collection with the result before being interrupted

any simple example around this to understand this scenario better. Please advise
0
gudii9Author Commented:
Thread A resumes execution but because thread B has modified the member field in the meantime, the collection that was populated with the database results is gone and replaced with an empty collection created by thread B.

you mean like below?

Thread A resumes execution but because thread B has modified the member field in the meantime, the collection that was populated with the database results is gone and replaced with an empty collection created by thread A.
0
Jim CakalicSenior Developer/ArchitectCommented:
database or DataSource?
database is the physical entity providing persistence. DataSource is the abstraction which could be a database (e.g., Oracle, MySQL) but could be anything that implements the interface. A servlet might have a DataSource injected on it or perhaps find one defined by the container using JNDI.

you means instance field of servlet right?
yes -- an instance field of the servlet

Thread A resumes execution but because thread B has modified the member field in the meantime, the collection that was populated with the database results is gone and replaced with an empty collection created by thread A?
No, I definitely meant thread B there at the end. Assume for the following that products is a servlet field declared as
private List<Product> products;

thread A                                       threadB
------------------------------                 ------------------------------
products = new ArrayList();
repository.load(criteria);
products.addAll(databaseResults);
                                               products = new ArrayList();
                                               repository.load(criteria);
if (!products.isEmpty())                       products.addAll(databaseResults); 
    for (Product p : products) 
        // do something with each

Open in new window


Assuming thread execution interleaves code as above, when threadA reaches the !products.isEmpty test, it will be false as threadB has set the products field to reference a new empty ArrayList and not added anything to it. If thread execution gets a little more complicated and threadB is able to add some (but not all) of its results to the collection before threadA reaches that test, then threadA will begin iterating over the collection as partially populated by threadB. If interrupted again and threadB continues to try to add results to the products collection while threadA is iterating it then I would expect a ConcurrentModificationException in threadA when it resumes because the collection has changed during iteration.

All three of these scenarios: empty list, partial list, exception are defects introduced by use of a non-synchronized field in the servlet resulting in an implementation that is not thread safe.
0
Jim CakalicSenior Developer/ArchitectCommented:
Here's an article that includes another example of a servlet that is not thread safe:
http://www.ociweb.com/resources/publications/sett/april-2000tips-for-creating-thread-safe-code-avoiding-race-conditions/
0
gudii9Author Commented:
In our example, I created a string that is an instance variable. This string is called a mutex (short for mutual exclusion) and is shared among all threads, thus ensuring that only one thread has access to the specified code block at any time.
I have not understood above approach clearely.
why we need mutex as in this link?
http://www.javaworld.com/article/2072798/java-web-development/write-thread-safe-servlets.html?page=2
we are synchronizing piece of code that is calling instance variable counter which is creating problem right?
why we need other instance variable mutex and refer as below
  synchronized (mutex)
    {    
      for (int c = 0; c < 10; c++)
      {
        resp.getWriter().println("Counter = " + counter + "<BR>");
        try

Open in new window

please advise
0
gudii9Author Commented:
The tag we want to implement is the javax.servlet.SingleThreadModel interface. The servlet container specification states that if your servlet implements this interface, you will be guaranteed that no two threads will simultaneously execute your servlet's service() method. Remember, service() is the underlining implementation for both the doGet() and doPost() methods, so we're safe.

How implementing SingleThreadModel  and service method (underlining implementation for both the doGet() and doPost() methods) are related so that we are safe?
please advise
0
Jim CakalicSenior Developer/ArchitectCommented:
Synchronization in the JVM is on an object. if you use the synchronized modifier to the method then the object used is the Class object on which the method is defined so only one thread can be executing any Class synchronized method at a time. When using a synchronized block, you provide the object on which locking is controlled. In the example you cite, the shared field is an int primitive, not an object. To synchronize access to it all access would need to be through synchronized methods or another object has to be introduced as the lock. It could be any type (include Object). This author chose a String to serve the purpose.

As an aside, it is unfortunate that the author chose to initialize the mutex with the empty string constant (""). Constants are interned by the compiler and shared within the JVM. Any other constant reference to the empty string will be the same String object. If this pattern is used thru the application (all mutexes are Strings initialized with the constant ""), then all synchronization will be controlled by the same object resulting in unrelated code sequences blocking each other.

SingleThreadModel is a "marker interface" used to warn the container that the instances of the servlet class implementing it cannot be shared across threads. The container then takes responsibility for deciding how to construct and pool servlet objects (if at all) to handle simultaneous requests. Since a compliant container will guarantee a unique object for each request, there is no concern with shared object fields and synchronization. Since it's a marker interface, there's nothing for the developer to do except add it to the implements clause. You should note, however, that it has been deprecated in the Servlet 2.4 spec. See the JavaDoc at the link.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java EE

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.