[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB
by timfox
The problem we have is this:
In the case of an MDB, the message is consumed from the underlying JMS provider *before* the MDB container has a chance to enlist the session in a global tx (this is the old design problem with ASF).
So the XASession needs to behave like a local transacted session if it is not enlisted in a global tx, otherwise, if it behaved like auto ack it would get acked immediately, then, some time later the onMessage gets called which is implemented by the StdServerSession which enlists the XASession in the global tx, at which point we _convert_ the work done previously in the local tx into the global tx.
So this is fine for the MDB case - the case where the session was created by the StdServerSessionPool.
However if the XASession wasn't created via the SessionPool - i.e. it's not a session for a transacted MDB, then we don't want it to fall back to behaving like a local transacted session, we want it to behave like auto_ack.
E.g. If in a method of an EJB, I use the JCA MCF to create a connection, session, then send a message, but no global tx is present, we want the message to be sent immediately - i.e. we want the XASession to behave non transactionally.
Also, in the same EJB method, we use the JCA MCF to create a connection, session, consumer, consume a message, then we want that message to get acked - i.e. the session to behave non transactionally.
This is the behaviour JBoss MQ has.
So, basicaly the session needs to behave differently depending on whether it was created via a session pool or not. But the problem is how to signal that to the session - I can't see how to do that.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041135#4041135
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041135
18 years, 11 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB
by weston.price@jboss.com
Adrian's comment are out of date. We always begin a transaction prior to the receive to support JMS providers where this is required (aka WebSpehreMQ). There was code at one point to be able to toggle this behavior on and off, but it has since been removed in the JCA adapter.
anonymous wrote :
| We have an XASession that is not enlisted in a global tx.
|
That's fine the underlying resource will simply not be enlisted. For inbound this is up to the JCA/JMS adapter which is described below.
anonymous wrote :
| In the case that XASession is created using a ServerSessionPool we want it to fall back to local transaction semantics. For all other cases we want it to have AUTO_ACK semantics.
|
I am not sure what you are asking. In the case of inbound messages the transaction behavior depends on the transaction attributes of the MDB. For CMT we use XA, for BMT and CMT/NotSupported we use local JMS transactions to support redelivery in the event of a RuntimeException.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041129#4041129
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041129
18 years, 11 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB
by timfox
This is what we need to work out:
"adrian(a)jboss.org" wrote :
|
| The JBossMQ behaviour is to assume that an XASession behaves like
| AUTO_ACKNOWLEDGE when the XASession is not enlisted in a JTA transaction.
| (Some JMS implements throw an exception in this case).
|
| There is one exception to this. When the XASession is being used as part of
| a ServerSessionPool, the semantics need to be receive then enlist.
| So for this, the XASession behaves like there is a transaction, it will be told
| later what XID to use for the 2PC protocol.
The question I still don't understand is how does the XASession know it is being used as part of the ServerSessionPool, so it can apply the different behaviour.
Looking through the code, I can't for the life of me work out how this information is passed from the ServerSessionPool to the session.
Can anyone (Adrian? Weston?) shed any light on this. This is becoming a bit of a blocker for us.
So to recap:
We have an XASession that is not enlisted in a global tx.
In the case that XASession is created using a ServerSessionPool we want it to fall back to local transaction semantics. For all other cases we want it to have AUTO_ACK semantics.
How does the session know which semantics to follow in the absence of a global tx?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041124#4041124
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041124
18 years, 11 months
[Design of JBoss ESB] - Re: jbossesb-properties.xml filters
by beve
Here is the error that is displayed in the server log:
| 17:46:26,356 ERROR [JmsGatewayListener] Unexpected problem
| java.lang.IllegalArgumentException: null 'value' arg in method call.
| at org.jboss.internal.soa.esb.assertion.AssertArgument.isNotNull(AssertArgument.java:40)
| at org.jboss.internal.soa.esb.message.format.xml.PropertiesImpl.setProperty(PropertiesImpl.java:62)
| at org.jboss.internal.soa.esb.message.metadata.MetaDataFilter.onOutput(MetaDataFilter.java:121)
| at org.jboss.soa.esb.couriers.filter.FilterManager.doOutputWork(FilterManager.java:81)
| at org.jboss.internal.soa.esb.couriers.JmsCourier.deliver(JmsCourier.java:157)
| at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.deliver(TwoWayCourierImpl.java:158)
| at org.jboss.soa.esb.listeners.gateway.JmsGatewayListener.doRun(JmsGatewayListener.java:165)
| at org.jboss.soa.esb.listeners.lifecycle.AbstractThreadedManagedLifecycle.run(AbstractThreadedManagedLifecycle.java:115)
| at java.lang.Thread.run(Thread.java:595)
|
I don't need the filters ( not for this quickstart atleast ). I'm using the jbossesb-server-4.2.MR1 that is created by 'ant dist' to test the quickstart. I'll try some of the others quickstarts and see if I get the same error when running them.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041064#4041064
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041064
18 years, 11 months