aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes The best way to return a value from an MDB. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "The best way to return a value from an MDB." Watch "The best way to return a value from an MDB." New topic
Author

The best way to return a value from an MDB.

Jay Damon
Ranch Hand

Joined: Jul 31, 2001
Posts: 282
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

Joined: Jul 20, 2005
Posts: 10101
    
164

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.


[My Blog] [JavaRanch Journal]
Robin Collier
Greenhorn

Joined: Feb 09, 2003
Posts: 7
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

Joined: Aug 21, 2008
Posts: 383
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

Joined: Jul 20, 2005
Posts: 10101
    
164

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

Joined: Jul 31, 2001
Posts: 282

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

Joined: Jul 31, 2001
Posts: 282
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 ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: The best way to return a value from an MDB.