[The background to this mail, may be found in the message forum:
http://www.jboss.org/forums/thread.jsp?forum=48&thread=4209]
Hi, Hiram and you other JBossMQ hackers. I have made a try to
reimplement the ServerSession(Pool) stuff so that it should potentially
become really (;-)) spec comliant and be able to handle the case where
more than one message is stuffed into the session (the chance are great
that it will ease integration with SonicMQ and SwiftMQ).
To do this I tested to make the StdServerSession a MessageListener and
make the session actually call StdServerSession and have the transaction
stuff in the onMessage. The TX stuff was therefore moved from
StdServerSession.run() (which calles the session.run()) to a new
onMessage method in StdServerSession (which then calles the container
invoker).
It does not, however, work as expected. What I can see I get this
behaviour:
1. If a rollback occures the message is not acknowledged and stays in
PM.
2. But no more attempts are made at delivering it.
As far as I can see all things are equals, except that the normal
restore is not run.
I.e a rollback in this code will roll the ack back, but no redelivery
will be tried, which I guess is not correct behaviour.
I poked a round in the code, and I wonder if it is these lines of codes
that make it:
After the message has been delivered to the listener this is done:
if ( session.transacted ) {
session.connection.spyXAResourceManager.ackMessage(
session.currentTransactionId, message );
} else if ( session.acknowledgeMode == session.AUTO_ACKNOWLEDGE ||
session.acknowledgeMode == session.DUPS_OK_ACKNOWLEDGE ) {
message.doAcknowledge();
}
Could it be, that when the TX stuff is in run() (i.e the commit/rollback
stuff will be run after this method has returned, this works because it
overrides the ack, but when the TX code is in the listener, the ack will
be run even if the receipt was acually a rollback.
I am not shure in what regards we should consider this a bug or not, but
I do know that it will not work to load a session with several messages
for the ASF part, since this will lead to the fact that several messages
will be run under a single transaction, which is not allowed according
to the EJB 2.0 spec. Therefore we must either forbid more than one
message a time, move the TX code into the onMessage part, or create some
cind of non spec compliant callback interface (as weblogic and the ri
has done).
Or is it something else playing tricks here?
//Peter
--
------------------------------------------------------------
Peter Antman Technology in Media, Box 34105 100 26 Stockholm
Systems Architect WWW: http://www.tim.se
Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
------------------------------------------------------------
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
