Tracing the code, I discovered that the Component (or Service) Layer does use Transactions, and the Rollback or Commit is done by this method in EntityTransactionModule.cs:
protected void OnEndRequest(Object sender, EventArgs e)
{
HttpApplication application = (HttpApplication) sender;
HttpContext context = application.Context;
TransactionManager mgr = ConnectionScope.Current.TransactionManager;
if ( mgr != null && mgr.IsOpen )
{
if ( context.Error != null )
{
mgr.Rollback();
}
else
{
mgr.Commit();
}
}
}
So I found out that the problem is elsewhere. There are cases where a Rollback should be done, but context.Error is null because I used a delegate earlier to handle the exception. The error was taken car of, but I still would like to be able to do a Rollback. There are two scenarios to solve this, and I'm not sure which one I should be using:
1) One solution would be to raise a flag when an exception is handled and to check that flag too in the above method. Something like:
if ( context.Error != null || flagIsRaised )...
With this scenario, I am not sure where the flag should be declared. Any suggestion?
2) Another solution would be to do the Rollback in the Error Handling Delegate. In this case however, I have to make sure that no other INSERT/UPDATE is taking place after the Rollback is done. Let me explain. If submitting a web page triggers the insertion of entities A, B, C and D, and an error occurs while validating or inserting B, a Rollback should be done so that the insertion of A does not take place. On top of this, I have to make sure that the insertions of C and D won't take place. Here again, I could raise a flag when an exception is handled. I could then add code in the processors of all entities to check that flag and prevent an INSERT/UPDATE to take place if necessary. The code could also be added in the Insert()/Update() methods instead. Here again, I am not sure where the flag should be declared.
Of the two scenarios, is there a best practice?
Cheers!
JF