• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Emulating Threads

 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Word has it you're not supposed to use threads in an EJB. I have a task that I want to run from an app server (in my case JBoss) a limited number of time in parellel. For instance, 4 at once, but not more than 4 since that would overwelme the server. These tasks can each take up to 30 seconds, and I need to design this so it can deal with 1000 or so sitting in a queue waiting to be run. (A little quick math says the jobs at the tail end may wait up to 8 or so hours before being run.)
I would like to run this inside the app server, since that's where all the business logic and method that will be called already resides, as opposed to running some external application.
Thoughts?
-Pete
<a href="http://www.budget-ha.com">Budget High Availability</a>
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This seems to be a clear-cut case for asynchronous processing via JMS + MDB. You even used the magic word: queue.
 
Peter Daly
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Chris,
JMS with a queue is my initial thought as well. But how do I limit it to X number of transactions being processed at once?
Take this a step further and think of a cluster. I want the whole cluster to only try to process (number of nodes)*2 transactions at a time.
Thanks for the JMS suggestion, I should have mentioned that, but my real problem is limited the number being processed. Limit to 1? I know how to do that. Limit to a number greater than 1, especially across a cluster? I have no idea.
-Pete
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Take this a step further and think of a cluster. I want the whole cluster to only try to process (number of nodes)*2 transactions at a time.


Ok. We've reached an area that I'm not too confident about (that happens a lot) but here it goes...
The pool size for an MDB in a clustered environment means "per server", i.e. pool size "2" for a cluster of 4 server instances means that there are a total of 8 (2 x 4) listeners for your (distributed!) JMS queue.
 
Peter Daly
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Limiting the pool size sounds like what I need to do, and the conclusion I was coming to as well through some research.
I'll look more into that.
Thanks both of you so much for your help!
-Pete
 
reply
    Bookmark Topic Watch Topic
  • New Topic