Transactional message driven beans were originally designed to receive
one message per transaction. However I have a faint recollection that
people have sometimes complained that this is too limiting...
It doesn't have to be this way....
Normally transactional message delivery to an mdb has transactions
managed by the receiving ejb container. The inbound connector says
its about to deliver a message, the container starts the tx, the
message gets delivered, and the transaction completes.
However there's also a transaction import capability for inbound
connectors. If the broker had some way to generate appropriate xids
(such as a tm running inside it) it could start a transaction, deliver
a bunch of messages, and complete the transaction itself. There are
(at least) two resource managers involved -- the broker and the mdb
container -- so xa transactions are really required for reliability,
but it might be possible to use the brokers journal as the tx log to
reduce the overhead. (basically this involves writing the prepare
record for the broker last, at which point it serves as the tx manager
"prepared" record as well -- you need to include a little extra info
in the record for this to work)
Implementation details aside, is this something anyone would use or is
it just a useless product of my fevered imagination?
I could see two obvious uses --
1. receiving all messages in a message group in one tx. I think this
would require either knowing how many messages are in the group to
start with or somehow flagging the last message in the group.
2. batching receives to reduce the overhead of transactions. If
transactions never roll back except for system errors then the
overhead of transaction management can be spread over 10 or 100
messages while maintaining transactional reliability.
many thanks
david jencks
