aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Discussion: Multi-Threading & EJB Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Discussion: Multi-Threading & EJB" Watch "Discussion: Multi-Threading & EJB" New topic
Author

Discussion: Multi-Threading & EJB

Musab Al-Rawi
Ranch Hand

Joined: Aug 06, 2007
Posts: 231
Hello All,

As we all know, we can't instantiate threads from within EJBs. But the question is:
Do we need threads, to perform operations faster may be, or to split a lengthy transaction?

Of course dealing with threads directly is tricky and probably that's one of the reasons why it is forbidden in EJB, but if there is a solution that provides the feeling of threading how far would you need it and use it?

Please think of this post as a think-out-loud post, so everyone's participation is highly appreciated.

SCBCD - SCWCD - SCJD - SCJP - OCA
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


As we all know, we can't instantiate threads from within EJBs. But the question is:
Do we need threads, to perform operations faster may be, or to split a lengthy transaction?

Yes. And we are using them in an EJB applicaiton its just the EJB container is making the decision when to spawn new threads.


Of course dealing with threads directly is tricky and probably that's one of the reasons why it is forbidden in EJB, but if there is a solution that provides the feeling of threading how far would you need it and use it?

Its not any difficulty that prevents you using threads; it is the domain of the EJB container and so the spec. forbids it.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Musab Al-Rawi
Ranch Hand

Joined: Aug 06, 2007
Posts: 231
Yes the container decides when to spaawn a new ejb but at the end when an ejb client invokes a method it will have to wait (block) until it's over.
When I said multi-threading i meant that the client won't have to wait, instead run the method in a seperate thread.
Steve Wink
Ranch Hand

Joined: May 13, 2002
Posts: 223
If you have a very long lived action then are EJBs the correct choice?

If you do wish to have something create threads and run for a long time in an app server there is the JCA spec, but I think you'd have to have a really good reason to use it.
Musab Al-Rawi
Ranch Hand

Joined: Aug 06, 2007
Posts: 231
What about using MDB for operations that might take a long time?
Steve Wink
Ranch Hand

Joined: May 13, 2002
Posts: 223
EJBs have transaction timeouts, MDBs as well as session beans, so you could reconfigure the transaction timeout, but you may get unwanted side effects if you have really long timeouts - I'm not sure how that would affect the datasources being enlisted in a transaction for a long time, or you may end up with a huge number of open transactions and overwhelm the transaction manager. I guess it depends on how long is long lived. I know WAS has 2 minutes by default, so 3 minutes for example may not have a huge impact. 30 minutes though may be a different matter.
Chris Hurst
Ranch Hand

Joined: Oct 26, 2003
Posts: 396

You can use a work manager if your container supports it (yet) , its morally ok to ask the container for a thread and allow it to determine if it should create or allocate you an existing one from a pool .

The devil is in how your 'work' communicates the results ;-), I use that with my JCA in Glassfish and communicate out via MDB.

This might be useful or chekc your container documentation...

http://www.devx.com/Java/Article/28815


"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
Steve Wink
Ranch Hand

Joined: May 13, 2002
Posts: 223
Chris Hurst wrote:You can use a work manager if your container supports it (yet) , its morally ok to ask the container for a thread and allow it to determine if it should create or allocate you an existing one from a pool .

The devil is in how your 'work' communicates the results ;-), I use that with my JCA in Glassfish and communicate out via MDB.

This might be useful or chekc your container documentation...

http://www.devx.com/Java/Article/28815


Do you find any problems with classloading in Glassfish - we have a JCA adapter that shares classes with our main application. This works fine in WAS, but in Glassfish the classloading order means that our shared classes are loaded in the JCA container. When our application then uses those classes, Glassfish give it the instances that were loaded in the JCA container, which causes problems when they then try to access resources that exist only in our application ear.
Christian Gossart
Ranch Hand

Joined: Mar 13, 2008
Posts: 34
Sorry if you were aware about this, but it seems that some of these issues (sync/async answer of an EJB) are addressed by EJB 3.1: EJB 3.1 Features with the @Asynchronous annotation and the support of java.util.concurrent.Future<V>

I admit I have not yet use it (currently working on JEE 5 projects), but this sounds pretty interesting.


Christian Gossart
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 29219
    
134

Another alternative is to turn your large transaction into multiple small ones. You may even be dong that with threading. The difference is you let an MDB handle the smaller pieces without threading yourself.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Chris Hurst
Ranch Hand

Joined: Oct 26, 2003
Posts: 396

Do you find any problems with classloading in Glassfish - we have a JCA adapter that shares classes with our main application. This works fine in WAS, but in Glassfish the classloading order means that our shared classes are loaded in the JCA container. When our application then uses those classes, Glassfish give it the instances that were loaded in the JCA container, which causes problems when they then try to access resources that exist only in our application ear.


No but i have few classes I use in the JCA that I use out and the couple that are are plain POJO's the only issues I could think off you might have with class loaders are class versions or static's neither of which I have. (I may just have got lucky ;-) but it seems to work very well)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Discussion: Multi-Threading & EJB
 
Similar Threads
EJb & Threads
Threading in containers
Can we use thread in ejbs ?
New to java
SMT