On Sep 1, 2008, at 11:52 AM, Juergen Weber wrote:
djencks wrote:
On Aug 30, 2008, at 1:08 AM, Juergen Weber wrote:
On Fri, Aug 29, 2008 at 7:29 PM, David Jencks
<[EMAIL PROTECTED]> 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.
By this argument remote ejbs and web apps violate the jee specs as
both use sockets to receive incoming messages. In all three cases
the
socket is handled by a server component (ejb container, web
container,
or jms provider) rather than application code.
Yes, if the container does the socket listening it should be no
problem.
Furthermore, at least activeMQ offers in-vm transport that does not
use sockets at all.
Seems like the scenario waiting for several messages is not
covered by
the J2EE spec, is it?
AFAIK it is not directly covered.
I am planning now to use a database to temporarily store the incoming
messages. In the transaction opened by onMessage() I can write to the
database and then commit the message read. The database is the last
partner,
so there is no need for XA.
I'm not entirely clear on what you are proposing, but I believe it
relies on the ability to process the same messages an indefinitely
large number of times with no bad side effects. The failure
scenario....
-- ejb reads all messages
-- ejb writes data to db, commits
-- ejb crashes before acking messages.
Later the jms container will attempt to redeliver the messages. As
long as you can figure out that the messages have already been
processed by looking at the data in the db, you should be able to
avoid xa.
thanks
david jencks
Thanks,
Juergen
--
View this message in context:
http://www.nabble.com/MDB---reading-messages-in-transaction-tp19223806s134p19259102.html
Sent from the Apache Geronimo - Users mailing list archive at
Nabble.com.
