Not quite. If you apply the patch I sent to the mailing list for the transactions a few days/weeks ago, you can decorate your method with [InjectTransaction] and have a parameter: "ITransaction tx" which then will have a method: "SetRollbackOnly()" which you can use to roll the transaction back. I needed it personally for the file transactions, when there were problems which I validated against but didn't throw.
(Also only getting the innermost exception instead of the full stack-trace can probably cause you some trouble in the future when you don't know what code-path the thing went down.) Transactions with the default [Transaction] or [Transaction(TM.Requires)] will join ongoing transactions and if the transaction is across resources such as FtX or different databases or the transacted message queues in Win-Vista/2008 the DTC (Distributed Transaction Coordinator) will start and take over the transaction. In your case though, you have _a lot_ of things going on in your controller and you should definitely move it to a few domain and application services to maintain separation of concerns. That way you can also expose them as web services should you need to. May I ask how come you're returning view datas from your controller? Which view engine is that? Cheers, Henrik -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jan Limpens Sent: den 10 juni 2009 22:43 To: Castle Project Users Subject: Re: Troubles with Automatic Transaction Facility (or something completely different) > 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 -~----------~----~----~----~------~----~------~--~---
