Thread safety in web application

Question

This question has been over my mind for quite a few days. For a customer based web application where many users are accessing the site, do I need all my back-end java classes to be thread safe? E.g if my web app is being accessed by 100 customers, will each of the request have separate set of java objects allocated to them in jvm? I'm working on a web project where none of the classes are synchronized and I wonder how multiple http requests don't share the same object?

Answer 1

Your typical web application has objects like servlets, controllers, services, and data access objects, which have no conversational state and so can be accessed safely from concurrent threads. Then there are persistent entities that are created by a request thread and usually don't get passed to other threads, their scope is confined to the thread that created them.

There are some infrastructure objects, like the connection pool and the Hibernate session factory, that need to be designed to be threadsafe. But if you're using any kind of reasonable framework you usually don't have to create these kinds of things yourself.

The most likely source of errors for your application, assuming you manage to avoid keeping state inappropriately in things like services or controllers, is probably going to be having database operations interleaved in an unintended way due to developers who don't know how to use transactions. That's what I would look out for. So 3 things:

1) avoid conversational state in services, controllers, daos,

2) use a framework (spring is one example) that provides proven threadsafe infrastructure, and

3) learn about database transactions, and isolation levels, and optimistic locking, and use them to make sure data is accessed or changed by different threads without corruption.

Answer 2

Depends on the purpose of your web app and the objects that are being handled. If your web app was just a simple tool then you could just keep all your objects and other data within scope, and you wouldn't need to worry about thread safety.

An online calculator or a pig latin translator would be examples of tools that would not need to worry about thread safety.

Once you start dealing with persistent data and concurrent access to this data will you need to start thinking about thread safety and the concurrency issues that might occur.

An online store where users are checking stock levels and making purchases would be an example of an application that would require some thread safety (assuming the data is stored within the application). You can't have one thread (user) try and retrieve an item while another is iterating over it trying to find another. A cache would be a better example than a store using static memory for string it's items.

In your example, where 100 users are accessing your application, each customer would access a separate instance of your application. This means that the data they post/ receive is isolated to their own interaction with the application and any changes to the data would be saved locally. If you want users to post/ get data from a shared source then you need to look into how you might go about thread safety and ensuring concurrency.

To answer your question more explicitly;

If you do not have any static container types storing data, then no, you don't need to worry about thread safety. This is because there is no common interaction between threads.

If you DO have a static container type for storing data, then it's very likely you will need to consider thread safety to ensure all threads can access the data safely.