Invoking threads from a J2EE application

Discussions

Performance and scalability: Invoking threads from a J2EE application

  1. Invoking threads from a J2EE application (4 messages)

    Hi, The EJB 2.1 specification explicitly prohibits invoking new threads from an EJB: "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, it is recommended not to invoke threads from servlets, as they are not 'thread safe', and the behavior will not be deterministic especially in clustered distributed environments. That said, there are real performance benefits that could be got when using multi-threading to tackle mission-critical or other performance-hungry sections of the application. We're facing a very large project, and there's a debate going on whether to use multi-threading in some sections of the system to boost performance. I would like to know if anyone, especially in very large J2EE projects, has broken the "no threading" rule, and to what effect. Was it successful? Did it cause too many problems that made you find another spec-friendly way to solve the problem? Any other insights? Thanks in advance, Raz
  2. Have you considered using javax.resource.spi.work.Work and associated javax.resource.spi.work.WorkManager. This part of J2EE spec lets you start threads in managed way. Cheers, Hubert.
  3. Re: Invoking threads from a J2EE application[ Go to top ]

    The issue with starting and stopping your own threads is that the application server does not know they exist, and so cannot do any sort of resource management with them. But at the end of the day, it's just so darned useful that plenty of people end up doing it anyway. Various application servers provide their own custom method for getting hold of managed threads. Take a look, for example, at commonj which you can use with WebLogic and WebSphere. We did start our own background threads on an older version of WebLogic (6.1 to be exact), before commonj became available. It worked, we had no problems with it and it caused no problems for us once we worked out a few teething problems (the sort of thing you always run up against with threads). Having said that, this may not hold true for other application servers or even later versions of WebLogic. Your mileage may vary, as the saying goes. Your best bet is to find out if the application server you are using supports custom thread creation, and use commonj if you're using one of the supporting app servers. If none of these apply, I would say go ahead and suck it and see.
  4. I already had such a problem before. The best way we found to solve this problem is by message passing to a message-driven EJB. This solution does not block the called EJB and does not create any workaround on the "no threads" rule of Java EE. In short, this solution flow goes like: 1 - A client C (Swing, Applet, Servlet, Web Service etc...) calls a performance intensive method from a Session EJB called S. 2 - S sends a message through JMS to a MDB called M requesting the later to process the request. 3 - S sends back to C a response which tells C that the request started to be processed. 4 - C understand the request will take some time and shows to the user a nice "wait a second..." animation. 5 - After some time, M may: a) (if C is Swing or Applet) send to C a JMS message or b) (if C is a Servlet or Web Service) rise a flag that must be read by C's initiative (AJAX-like periodic requests) A good rule of thumb for performance is "assynchronous Java EE means message passing".
  5. Maybe this can help :)[ Go to top ]

    Hi Raz,
    I am not a J2EE developer (as you already know).
    But I can tell you that splitting tasks to more threads will not make things run faster regardless of the coding language.
    The speed in which internal tasks are completed are in direct reference to the amount of cpu's used to complete a task.
    since most servers use 4 cpu's and most coding language will not let you assign which cpu do which task.. you can not really control the speed of let's say 100 tasks, but you can tell the cpu to split it's time between the tasks so they will be done in parrallel.
    let's say for the example i want to count from 1-100 in one thread and it takes me 10 seconds to complete this.
    Counting from 1-10 in 10 threads will not happen in less than 10 seconds.
    hope this helps and good luck.