In the principle of more discussion :)
I've always been wary of automatic retries as I've been aware of the NH mantra "when a session throws an exception you cannot be sure of it's current state; it's best to discard that session and start again". However, I've never dug into the codebase to understand why and, in reality, I have coded retry blocks around queries in a session anyway, as opposed to around a Flush, If the flush fails, then I discard the whole session and start again and this seems to work ok. This means that the way I handle it is that flush failures need to be captured at the business level (aka transaction boundary), it ties in nicely we retries due to state state et, and fits better with the advice not to trust the state of the session after an exception. For queries I've added extension methods (e.g. ExecuteWithRetry) so that I know I can retry automatically if appropriate, and not if I don't need to. For cloud services such as Azure, Microsoft make available the transient exception error block, which is quite easy to implement and then (in my designs) I can use this to decorate my transaction boundaries to handle transient exceptions cleanly. The advantage of this is that it comes with the exponential backoff handler that is to recommended for retry logic. Therefore (IMO) a simple "fail then retry once because the connection has been dropped" (e.g. the ADO.NET connection pool has a bad connection to SQL Server) is fine, but anything more complicated should be left well alone. -- --- You received this message because you are subscribed to the Google Groups "nhibernate-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to nhibernate-development+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
