geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holger Baxmann <>
Subject Re: MDB - reading messages in transaction
Date Sat, 30 Aug 2008 09:49:31 GMT

Am 30.08.2008 um 10:08 schrieb Juergen Weber:

> On Fri, Aug 29, 2008 at 7:29 PM, David Jencks  
> <> wrote:
>> On Aug 29, 2008, at 9:59 AM, Juergen Weber wrote:
>>> Hi,
>>> can a Geronimo message driven bean read several messages in a  
>>> transaction?
>>> E.g. data might be split in several parts, one message for each  
>>> part, and
>>> the messages should not be removed from the queue until the MDB has
>>> received
>>> all parts and has acknowledged having read all parts?
>> not directly.  No MDB can read more than one message in an  
>> invocation.
>> You might possibly be able to have your mdb open a connection and  
>> listen for
>> the rest of the mesages that go together but you'll have to do some  
>> extra
>> configuration such as making sure all the messages are in a message  
>> group so
>> they all go to the same mdb.  This would probably only work with  
>> ActiveMQ
>> and very well might not work at all.
>> You might be able to do something with a stateless session bean  
>> called from
>> a controller that opens a connection and reads all the messages in  
>> a group.
>> I think this is more likely to work than an mdb.
> But this would violate the J2EE spec, as an EJB would need to wait for
> incoming messages which would quite certainly mean listen on a socket.
> Seems like the scenario waiting for several messages is not covered by
> the J2EE spec, is it?


as far as I can remember, this seems to me like a layer 8 decoupling  
problem. One abstraction layer above JEE adressables.
In general, one can say: One Queue is not enough. For full decoupling,  
but providing transactions, you need at least two. On both sides of  
the producer->consumer->producer decoupling.

There are serveral documents about this n inbox msgs -> outbox ->  
inbox transactional designs. One example is the combination of your  
"parts" aka transactional command (

) and completion callback ( 
), some other could be found on  
espacially in "Loosely Coupled: The Missing Pieces of Web Services".

But the implementation depends, because of "Layer 8", mostly on the  
business needs and design, here the content and behavior of the  
transactional commands aka "parts" in your business process.
A generic one should not beeing able to accomplish. That's why out  
there are the transactional BPM and the workflow patterns (

) with it.

just 2ct

View raw message