• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

The best way to return a value from an MDB.

 
Jay Damon
Ranch Hand
Posts: 282
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The "gurus" at the company I work for have mandated using message driven beans to perform computationally intensive tasks, for example calculating a maximum amount which typically takes 5-10 seconds. I think I understand MDBs well enough to put an object on the queue, retrieve it in the onMessage method of the MDB and perform the necessary calculation. However, what is the best or proper way to return that value back to the object that needs the value?
 
Jaikiran Pai
Marshal
Pie
Posts: 10444
227
IntelliJ IDE Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since the call is asynchronous, the "client" (i.e. whoever put the message in the queue) may no longer be available. Usually the MDB on receiving the message does the logic (either directly or forwarding the request to some appropriate component) and stores the output to some place (ex: database). The client can then pick up the stored output at some later point in time.
 
Robin Collier
Greenhorn
Posts: 7
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would use another queue for the result object, and set the correlation id on the response to the JMSMessageID from the request message so the sender can find the specific result on the queue with a simple selector.

The result queue can even be sent in the originating message by setting the setJMSReplyTo().
 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just a question - does it make sense to use MDBs in this scenario? If you need to take a result, should you be using MDBs in the first place?
 
Jaikiran Pai
Marshal
Pie
Posts: 10444
227
IntelliJ IDE Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Raf Szczypiorski:
Just a question - does it make sense to use MDBs in this scenario? If you need to take a result, should you be using MDBs in the first place?


Depends on "when" the result is expected by the client. If the result is required before he can move onto the next step of processing, then MDBs (which are asynchronous) won't be of use. However, if the result of this heavy duty operation is required without blocking the further steps, then it does make sense to have MDBs (or any other asynchronous mechanism).
 
Jay Damon
Ranch Hand
Posts: 282
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Since the call is asynchronous, the "client" (i.e. whoever put the message in the queue) may no longer be available...

The "client" will be available as this is for a web application. The basic problem is that I know there are computationally intensive tasks that will almost always have to be performed (unless the user exits the application). Therefore, the idea is to spin off and perform those tasks asynchronously when a user enters a page so the required data will be readily available for subsequent pages.


Just a question - does it make sense to use MDBs in this scenario? If you need to take a result, should you be using MDBs in the first place?

That was my question as well. I considered WebSphere's WorkManager API to be more appropriate as it is simpler and offers more features. However, MDBs were mandated as the solution to the problem.


I would use another queue for the result object, and set the correlation id on the response to the JMSMessageID from the request message so the sender can find the specific result on the queue with a simple selector.

Robin, this appears to the answer I was looking for. The use of a correlation id should allow me to identify the appropriate message of the queue. Thanks!
[ November 12, 2008: Message edited by: Jay Damon ]
 
Jay Damon
Ranch Hand
Posts: 282
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another question: I was thinking of setting up one input queue and one output queue for this purpose to keep the design as simple as possible. Are there any performance issues I should be aware of? I am aware that processing may not be complete by the time I actually need the data. That is okay as my application is coded to perform the task inline if no result is available.

Finally, another question arose in my mind as I was writing this post. What about the web application users that do, in fact, exit the application prematurely? This would potentially leave thousands of unconsumed messages on the queue. What would be the best way to handle unconsumed messages? If I set a expiration value (i.e. setJMSExpiration) will that cause the message to be removed from the queue at the expiration time?
[ November 12, 2008: Message edited by: Jay Damon ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic