> Catching all exceptions will make the transaction try to commit. So the only way to stop a transaction from committing would be to actively throw an exception and present it to the user as a rescue? I thought, the transaction would have been rolled back, before the exception was thrown to me. I am quite in a bit of trouble, if this is as you say...
> Could you send a small .sln with a repro? I will try... > You're kind of eating the exceptions in a lot of places... Have you tried > letting the exception bubble out of the action instead, using a > [HandleError] page? Actually I am catching my exceptions at the last possible instance, at the controller, where I am actually in the position to do something about it, if at least informing my users or redirecting or trying some different approach. Most of the transaction intensive actions (form post actions) use JSONReturnBinder. I use a defined Json format to inform my users of possible errors. Dunno if I can use a [HandleError] page (== rescue??) here. In this special case everything goes fine database wise. The transaction _should_ commit, but it does not due to a failure in a totally different service. Thanks! Jan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en -~----------~----~----~----~------~----~------~--~---
