Bug report: http://jira.jboss.com/jira/browse/JBAS-5571
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154702#4154702
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154702
___
Ok, I see the problem. So there's two ways to fix it.
1) We come up with some mechanism where the ServerIL's transact() request
can vote READONLY in this case.
This would require a mixin interface like the Recovery interface
such that newer clients can take advantage of it.
i.e. something like
I seem to be having trouble posting to this forum - here's another go (sorry if
it comes through multiple times):
anonymous wrote : I don't understand this? If JBossMQ doesn't return the XID
then the TM
| must assume it was committed.
If the JBossMQ unilaterally rolls the transaction forward
"mmusgrov" wrote :
| This is a problem for TM recovery since the XAResource a for temporary
topic queue does not return XAResource.XA_RDONLY for the prepare phase. Thus
when the TM calls recover on the resource no xids are returned and hence the
transaction can never be recovered.
|
I don
The XAResource should not return XA_RDONLY because the Resource needs to see
the commit, otherwise any temporary subscribers would miss any messages
published to the topic within the transaction. I'm not sure what the correct
solution should be but I have raised a JIRA task (JBMESSAGING-1282) to
The remaining issue, then, is to do with how the JBossMQ XAResource handles
non-durable subscriptions:
If there are durable subscriptions for a topic then published messgages are put
on a peristent queue otherwise a temporary queue is used (see method
JMSTopic.addMessage(...)). It appears that
Actually, I did not install any durable subscribers for the Topic and
consequently there was nothing to recover. When I added a durable subscriber
and retested then the recovery system did indeed recover the message published
to the topic.
So the JBossMQ recovery support is working provided we
