Hi Christian, I updated the JMS Configuration page on confluence based on my experience with enabling transaction support for JMS. I added a note about being able to register a JMS Transaction Manager and that for 2.7 a transaction manager must be registered to get transactions in addition to sessionTransacted.
Can you have a quick look and make sure my comments are accurate On Sat, Dec 6, 2014 at 4:42 AM, Jason Pell <[email protected]> wrote: > OK I am going to revert my changes, add a config property to > JMSConfiguration to optionally disable exception propagation. > > The existing behavior will remain the default potential bugs and all. > > Cxf 3.0 won't need that property as that's the default anyway > On 06/12/2014 3:45 AM, "Daniel Kulp" <[email protected]> wrote: > >> >> Honestly, I have no idea on the transaction stuff in the JMS transport. >> I’m really not sure of the use cases where it’s needed or working correctly >> or as desired. >> >> For example, if the soap message isn’t valid and we cannot parse it, why >> should it be rolled back and retried? We’re not going to be able to parse >> it again next time either. If there are issues trying to send the >> response back to the client, sure. I can see that. But most of the >> others seem to cause more problems. >> >> >> Dan >> >> >> > On Dec 5, 2014, at 6:59 AM, Jason Pell <[email protected]> wrote: >> > >> > I think I could probably live with no rollbacks at all even inside a >> > transaction. That is certainly more consistent than cxf 2.x. Maybe we >> > don't even need to change anything in cxf 3. >> > >> > Perhaps we can change cxf 2.x so it behaves same way. At least make it a >> > config option. >> > >> > I could live with that as I agree with you the requestor can resend if >> > needed and its cleaner than the dead letter queue. >> > >> > I might take another stab at disabling all exception propagation in JMS >> > Destination. I can then ignore the session matching issue and move on >> with >> > my life :-) >> > >> > Be interested to get some background from Dan on why its there though... >> > On 05/12/2014 9:46 PM, "Christian Schneider" <[email protected]> >> > wrote: >> > >> >> For request/ reply: >> >> If you have a transaction then the message will be rolled back if cxf >> >> dies. In all other cases cxf should send back a reply with the eventual >> >> exception as a soap fault. >> >> I think this behaviour is what you expect as a requestor. >> >> >> >> As there are always some cases where the requestor will get no reply >> or a >> >> fault the requestor always has to include some code to resend the >> request. >> >> >> >> I am not against using optional rollbacks but we have to make sure we >> do >> >> not create unwanted behaviour. >> >> >> >> Maybe we should have a switch for to decide if rollbacks should happen >> in >> >> request/reply. On the other hand I try to have as few switches as >> possible. >> >> Every thing that is done optionally increases test effort and makes it >> >> harder to document / explain how it works. So we should be sure it >> makes >> >> sense. >> >> >> >> Christian >> >> >> >> On 05.12.2014 11:29, Jason Pell wrote: >> >> >> >>> I would like the option of enabling roll backs for runtime exceptions >> in >> >>> cxf 3 when I eventually upgrade. Does cxf 3 at least cater for a >> error in >> >>> middle of process where by the reply is never delivered but the >> request >> >>> has >> >>> disappeared so essentially there is no evidence of wother message. At >> >>> least >> >>> with the transaction even if it's just the spring JMS transaction >> manager >> >>> both messages will be delivered or neither will. >> >>> On 05/12/2014 8:44 PM, "Christian Schneider" <[email protected] >> > >> >>> wrote: >> >>> >> >>> >> >> -- >> >> Christian Schneider >> >> http://www.liquid-reality.de >> >> >> >> Open Source Architect >> >> http://www.talend.com >> >> >> >> >> >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >>
