If exception is really thrown inside this try-catch
block, it will be caught here. Try to set breakpoint to check this.
On the other hand, your view may use the same Session
(with locked transaction) further, and one more exception might be thrown there (note that the original error is suppressed by your catch
block). So in this case you'll really see it in Application_Error
.
How to fix the issue:
-
First way is to replace Transaction.Open()
to Transaction.Open(TransactionOpenMode.New)
. This will ensure the outermost transaction won't be locked in case of exception in your handler.
-
Second way is to ensure view won't use the Session
with locked transaction in case of error - e.g. by selecting special "error view.
-
You can try to start a new outermost transaction by hacking SessionManager
. This is possible, but you'll need to access its private members via reflection. In general, this is a bad idea - normally each web request is processed inside a single transaction.
-
You can manually open new Session
and transaction in your view in case of error, if this is really necessary. ~ The same case as 3, but without hacks.
Also note, that you can't catch SqlException
directly. You must catch one of our high-level wrappers (DeadlockException
, ConstraintViolationException
, etc. - all of them are descendants of StorageException
); original SqlException
can be found by unwinding InnerException
chain there.
answered
Sep 17 '10 at 00:59
Alex Yakunin
2971●4●4●12