[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XA resource and setting the timeout
by timfox
"jhalliday" wrote :
| So your options are: keep some meta data around after the timeout, so that you can reply 'rollback only'
|
If we keep some meta data lying around, we may as well just keep the transaction branch and not roll it back. At least that would give the tx mgr the opportunity to commit at some time too. It seems to me timing out without being able to delete the branch state in the RM seems a bit pointless.
anonymous wrote :
| , or throw away everything and reply 'unknown tx id'.
|
Seems sensible. At least then we can delete the state.
anonymous wrote :
| BTW, what's the perceived advantage to you in implementing timeouts at the resource level, given that users will (hopefully) set an overall tx timeout interval if they want one?
Set and getTransactionTimeout are on the xaresource API so would it's my understanding they would be called by the transaction manager?? If the tx mgr does decide to call them, then it's my assumption that we need to implement them in a way that doesn't break anything.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186362#4186362
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186362
15 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XA resource and setting the timeout
by jhalliday
The XA spec has this to say on the matter:
"An RM can mark a transaction branch as rollback-only any time except after a successful prepare. A TM detects this when the RM returns a rollback-only return code. An RM can also unilaterally roll back and forget a branch any time except after a successful prepare. A TM detects this when a subsequent call indicates that the RM does not recognise the XID. The former technique gives the TM more information.
So your options are: keep some meta data around after the timeout, so that you can reply 'rollback only', or throw away everything and reply 'unknown tx id'. It's up to the tm to deal with either of those cases. I don't off the top of my head know how well JBossTS will respond to either of them. I'm not aware of any major RM that uses either, so I suspect we'll run into seldom exercised corner cases.
BTW, what's the perceived advantage to you in implementing timeouts at the resource level, given that users will (hopefully) set an overall tx timeout interval if they want one?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186357#4186357
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186357
15 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Behaviours of Ordering Group with scheduled delivery and DLQ
by gaohoward
Scheduled Messages
Currently, Ordering group doesn't suppport scheduled messages. Although technically possible, in practical use these two features shouldn't be used together. Because in some sense they are functionally conflict. Using scheduled delivery meaning you want each of such messages delivered at certain point of time in future, namely those messages must be delivered in the order determined by their scheduled times. On the other hand ordering group requires messages to be delivered in the order of sent sequence.
DLQ/ExpiryQueue
If a message of an ordering group is 'dead' or expired, it goes to the corresponding DLQ or ExpiryQueue and the message will be ACKed. Ordering Groups treat those messages are correctly delivered and completed when controling the ordering group delivery. Therefore, the consumers would see some message 'hole's during the receiving of ordering group messages. The 'hole's won't prevent their succeeding messages from delivering.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186334#4186334
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186334
15 years, 5 months