2

Is a typical J2ee web application or any web app built on top java is multi threaded application , so every time i write some code i have to keep race condition or concurrent modification in mind ?

sumedha
  • 473
  • 1
  • 9
  • 24

3 Answers3

2

Is a typical J2ee web application or any web app built on top java is multi threaded application?

Yes, it is. But the application server (Tomcat, JBoss, WebSphere, etc.) handles the threads and resources for you, so you may not worry about race condition or concurrent modification.

When you should worry about concurrent modification? For example, if you happen to create a field in a Servlet and you update this field on every request (doPost or doGet method of the servlet), then two users in their pcs could perform the request on the same URL at the same time, and this field will have an unexpected value. This is covered here: How do servlets work? Instantiation, sessions, shared variables and multithreading, Threadsafety section of the accepted answer. Note that having a design like this is a bad practice.

Another case may be you firing new threads and resources shared among this threads by your own. It is not a good practice nor a bad practice, it is kind of you must understand the risk you're taking and assume the consequences. This means, you can have a Servlet and fire threads on your own, but it's up to you to handle this in the right way. Note that you should evaluate if you really need to fire and handle threads in your Java EE application or if you could use another approach like firing JMS messages that will handle multiple requests in parallel and asynchronously.


@AndreiI noted in his/her answer that EJB prohibits using threads, but this means that you cannot manage threads inside an EJB, nor by creating a new instance of Thread nor by using ExecutorService or any other. In code:

@Stateless
public class FooEJB {
    public void bar() {
        //this is not allowed!
        Thread t = new Thread(new Runnable() {
        //implementation of runnable
        });
        t.start();
    }
    public void baz() {
        //this is not allowed either!
        final int numberOfThreads = ...;
        ExecutorService es = Executors.newFixedThreadPool(numberOfThreads);
        es.execute(new Runnable() { ... });
        es.shutdown();
    }
}
Community
  • 1
  • 1
Luiggi Mendoza
  • 85,076
  • 16
  • 154
  • 332
  • I would say that this all argues that you *do* need to worry about race conditions and concurrent modification. In my experience, developers are all too eager and willing to make servlets and shared services stateful in a way that then comes back to bite them. It is better to be aware of the problem up front and work to avoid it than to try to debug and fix it after the fact. – David Conrad Mar 05 '14 at 17:42
  • @DavidConrad if you happen to have a good design of your servlets, then there won't be any race condition nor concurrent modification at all. That's why I pointed out BalusC's answer on this topic. – Luiggi Mendoza Mar 05 '14 at 17:44
1

Like almost any framework in Java (server applications, inclusive Web frameworks or GUI applications based on AWT or Swing), Java EE is multi-threaded. But the answer to your question is no: you do not have to care about race condition or concurrent modification. Of course you are not allowed to make some errors (like sharing Servlet variables), but in a typical application you do not care about such things. For example the EJB specification prohibits using threads, but it has a mechanism for asynchronous jobs. Excerpt from the EJB specification:

The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.

Also the most used interface in the JPA specification (EntityManager) is not thread safe, although others are.

V G
  • 18,822
  • 6
  • 51
  • 89
  • Yes it is. The EJB prohibits to manage threads inside it, but they live in a multi threaded environment. – Luiggi Mendoza Mar 05 '14 at 17:17
  • @LuiggiMendoza eveything is multi-threaded in Java, any kind of application: desktop, Web. But the question asks something else: is a typical Java EE dealing with threads? And the answer is NO. – V G Mar 05 '14 at 22:03
  • A Hello World application is not multi-threaded :). And you can open several threads in a Servlet which is a Java EE application. So, the answer is still: YES. – Luiggi Mendoza Mar 05 '14 at 22:10
  • That is not an application :) that is hello-world AND it runs also in a thread: the main thread. Threads are everywhere: simply starting the JVM starts multiple threads (e.g for garbage collection, finalization). You can also play with threads also in EJBs (although not allowed). THE BIG BUT: the OP asks whether in a typical application you care about race conditions+synchronization, and not whether you can open threads. PS: I reformulated a bit my answer, so thanks for insisting :). – V G Mar 06 '14 at 09:09
  • *Of course you are not allowed to make some errors* the sad true is that you as programmer are allowed to fall in those errors, since it is not restricted by Servlet specification, only the experience (from committing this mistake and fixing it or from somebody with this experience) might save you. – Luiggi Mendoza Mar 06 '14 at 14:25
0

In a Java EE application container the Server takes care of the threading for you. Typically it creates one thread per request. However using Spring or EJB you can declare different scopes to your threads. So, you should not have to directly manage threads in a JavaEE application.

jeremyjjbrown
  • 7,772
  • 5
  • 43
  • 55