File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Discussion: Multi-Threading & EJB

 
Musab Al-Rawi
Ranch Hand
Posts: 231
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Musab Al-Rawi
Ranch Hand
Posts: 231
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 225
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 231
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What about using MDB for operations that might take a long time?
 
Steve Wink
Ranch Hand
Posts: 225
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 443
3
C++ Eclipse IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Steve Wink
Ranch Hand
Posts: 225
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 34
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 33694
316
Eclipse IDE Java VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Chris Hurst
Ranch Hand
Posts: 443
3
C++ Eclipse IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic