| Author |
Message
|
| ITCrash |
 Posted: Tue May 18, 2004 12:16 pm Post subject: Message-Driven Bean with Websphere MQ |
 |
|
Newbie
Joined: 18 May 2004
Posts: 1
|
I am currently working on a Message Driven Bean (MDB). The MDB receives the message and then tries to process the message. It works fine if the message is a complete message. The problem I am having is that even sort messages are being split into multiple messages. I am testing the MDB by sending a message using the mqm user.
Is there a way to configure MQ to combine the messages for the MDB or a way for the MDB to wait for all the individual parts to execute the onMessage method? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu May 20, 2004 2:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
This is a very complex scenario
I don't believe that you will be able to realize it with an MDB.
I could image it being realized with a triggered process though.
You may have to tap into RMI or EJB client to communicate with WAS
Sounds a little bit crazy....
 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu May 20, 2004 4:18 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You could certainly do it with an MDB.
But the MDB would have to be able to maintain state in some way.
Probably the best (for J2EE values of "best") way to do this is to pass each message segment to an EJB. The EJB then has the responsibility of assembling the message pieces into a single message, and then doing the appropriate thing.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 21, 2004 9:51 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Jeff the reason why I doubt that an MDB would work is the transaction model.
Default transaction model on the MDB is each message. You can modify this in the setup but you would have to set it to a number big enough to never be reached and still do your own commits.
The advantage of a triggered scenario is that the commit can be made when the last message in the group is reached and successfully processed.
The client will have the responsability of assembling the paylod from the group and passing it to the EJB for processing.
If you have a better scenario please let us know.
Thanks
F.J.  |
|
| Back to top |
|
|
| bower5932 |
| Posted: Fri May 21, 2004 11:22 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| You could always try something like putting your messages onto one queue. When you are done, you could put a message onto the MDB queue that indicates the other queue is 'ready'. You could then go and get all of the messages. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri May 21, 2004 3:57 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| fjb_saper wrote: |
Jeff the reason why I doubt that an MDB would work is the transaction model.
Default transaction model on the MDB is each message. You can modify this in the setup but you would have to set it to a number big enough to never be reached and still do your own commits. |
fjb_saper -
I understand the transaction mode of the MDB.
My suggestion was to pass the contents of each message to some manner of stateful bean - session or entity - through a method.
The EJB then stores the data from each method somewhere, and returns a successful result to the MDB. This allows the MDB to commit the get, and move on to the next message.
The EJB then determines when it has a complete message and handles the actual processing of the complete message.
This is a standard aggregation pattern, cast into J2EE terms.
I make no claims or warantees on how easy, robust, scalable, manageable, or proper a method this is. I merely think it should be functional.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat May 22, 2004 10:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Hi Jeff,
I guess what we really end debating here is transactional integrity of the message vs transactional integrity of the payload (multiple messages) and ease of error handling in each case.
Putting together a correct error handling on the payload seems a little bit more prone to manual coding and errors using the MDB and the statefull session bean. But this may be a matter of opinion.
Thanks for your insight. I had not thought about committing the messages before assembling the payload. The idea has merit and allows you to stay within WAS, whereas a triggered approach requires access to a remote EJB interface. You would as well have to code the rejection mechanism to take advantage of the backout threshold.
F.J. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sun May 23, 2004 5:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Well, the transactional integrity of the message is still maintained.
It's just that the actual work within the Unit of Work is different. In the case where one is trying to assemble the message before committing one of the pieces, the work is to actually process the message.
In my example, the work is pass the message to the EJB. So if the EJB fails, or can't persist the message, then the message transaction gets rolled back.
But even then, the transactional effects are complicated and tricksy.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
