• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Discussion: Multi-Threading & EJB

 
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 225
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What about using MDB for operations that might take a long time?
 
Steve Wink
Ranch Hand
Posts: 225
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 443
3
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.

 
author & internet detective
Posts: 42105
933
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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)
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic