On Sat, 3 Oct, 2009 at 06:57, Claus wrote: > If you are using Camel 2.0 you got the onCompletion...
The onCompletion block seems to suffer exactly the same issue as the onException one: the transacted tag effectively disables it. Moving the onException block *after* the transacted tag doesn't work either: it gets treated like a regular block of code, and gets called all the time. Further, in an attempt to reproduce the issue outside of my application, I've discovered I was quite lucky to get onException working at all with transactions: it's only being hit because I have a split around my transacted block. No idea why that would be. > ...in Camel 2.0 you can also force a rollback... If I put a rollback tag in my onException path (in the rare case I can get that path to work at all), it somehow makes Camel enter an infinite loop. I'd be happy to raise this as a bug via JIRA, with my various attempts at solutions attached, if that helps. I kind of assumed error handling on transacted routes should "just work", especially as there is a passing comment to that effect in the docs. Now I will attempt some analysis, based on what I've seen trying to debug my code: The key to the problem seems to be that exception handling is not handled in a standard, Java-like way. I would expect the exception to propagate its way up to the outermost error handler, with intermediate blocks attempting mediation only if they have specific rules defined: for instance, the transacted error handler would only perform rollback, then rethrow the error. Instead, all error handlers attempt to completely handle the error, and all blocks without explicit error handlers copy the outermost one -- except for <transacted /> which creates a new TransactionErrorHandler. This works fine if there is only one error handler, but causes lots of problems when, as in my case, there are two. It would also cause problems for transacted blocks with nested blocks inside -- which hold a copy of the outermost, non-transactional error handler -- except the DefaultErrorHandler has explicit code to disable itself if there is a transaction. This would not be necessary under a propagation-based scheme. Cheers, Chris ********************************************************************** Please consider the environment before printing this email or its attachments. The contents of this email are for the named addressees only. It contains information which may be confidential and privileged. If you are not the intended recipient, please notify the sender immediately, destroy this email and any attachments and do not otherwise disclose or use them. Email transmission is not a secure method of communication and Man Investments cannot accept responsibility for the completeness or accuracy of this email or any attachments. Whilst Man Investments makes every effort to keep its network free from viruses, it does not accept responsibility for any computer virus which might be transferred by way of this email or any attachments. This email does not constitute a request, offer, recommendation or solicitation of any kind to buy, subscribe, sell or redeem any investment instruments or to perform other such transactions of any kind. Man Investments reserves the right to monitor, record and retain all electronic communications through its network to ensure the integrity of its systems, for record keeping and regulatory purposes. Visit us at: www.maninvestments.com TG0908 **********************************************************************
