Oskar, Right, this issue should be considered together with NH-3607 (Resilient Connection Provider).
RP On Wednesday, September 3, 2014 7:31:46 PM UTC+1, Oskar Berggren wrote: > > 2014-09-03 1:16 GMT+02:00 Ricardo Peres <rjp...@gmail.com <javascript:>>: > >> Oskar, >> >> You are right, as usual! But my idea is to have a *pluggable* mechanism. >> The default, I admit, would be a bit dumb - just try... wait... retry... >> fail - but we could have more enhanced ones. Right now, all we have is an >> exception! :-) >> > > > I'm afraid I don't quite follow. Considering the code in PR #306, the way > I read it, that code in the default connection provider could exhibit the > failure mode described below (assuming an ADO.NET connection can go from > OPEN to CLOSED without an exception). And I don't see any retry logic? > > I don't have enough time to think deeply on it, so maybe I'm missing > something. > > /Oskar > > > On Tuesday, September 2, 2014 9:36:43 PM UTC+1, Oskar Berggren wrote: > >> I'm not sure what the different failure modes are here... but here's one >>> scenario I'm thinking about: >>> * Inside non-distributed transaction. >>> * Some changes (changeset X) flushed to DB. >>> * Connection is lost. >>> * A new connection is created transparently. >>> * More changes (changeset Y) flushed to DB. >>> * Application tries to close transaction. >>> >>> Wouldn't this patch: >>> a) Loose changeset X, because the transaction was never committed and >>> the application wasn't made aware of the problem? >>> b) Get exception when trying to commit a non-existing transaction over >>> the second connection? >>> c) Permanently store changeset Y even if the exception mentioned in (b), >>> or some other exception, occurs due to lack of transaction on second >>> connection? >>> >>> /Oskar >>> >>> >>> >>> >>> 2014-08-20 23:26 GMT+02:00 Ricardo Peres <rjp...@gmail.com>: >>> >>> I see this as something to make NH more reactive to scenarios such as >>>> cloud, where connections are lost and need to be open, similar to what EF >>>> is providing. What the default implementation does is, if the connection >>>> is >>>> closed, open it. Do you see problems related to transactions with this? >>>> Obviously, this can wait for more discussion. >>>> >>>> RP >>>> >>>> >>>> On Wednesday, August 20, 2014 9:48:44 PM UTC+1, Oskar Berggren wrote: >>>> >>>>> Is this a problematic scenario that requires a solution? >>>>> How does it relate to ConnectionManager and the behavior of open/close >>>>> connection on transaction boundary? Interaction with TransactionScope - >>>>> might it cause unforeseen transaction promotions? >>>>> >>>>> >>>>> /Oskar >>>>> >>>>> >>>>> >>>>> 2014-08-20 14:27 GMT+02:00 Ricardo Peres <rjp...@gmail.com>: >>>>> >>>>> Guys, >>>>>> >>>>>> I created issue NH-3671 and added a pull request. The idea behind it >>>>>> is: >>>>>> >>>>>> - Before NHibernate issues DB operations, through calls to >>>>>> IDbCommand.ExecuteQuery, ExecuteReader or ExecuteScalar, it should call >>>>>> a >>>>>> new connection provider method, IConnectionProvider.EnsureConn >>>>>> ectionIsOpen >>>>>> - The base implementation in ConnectionProvider (virtual method) just >>>>>> does: if (conn.State != ConnectionState.Open) conn.Open() >>>>>> - More enhanced (aka, resilient, like NH-3607) connection provider >>>>>> implementations can retry a number of times with a delay between them >>>>>> >>>>>> I see two potential problems: >>>>>> >>>>>> - It introduces a breaking change on IConnectionProvider, because it >>>>>> adds an additional method >>>>>> - Not all DB calls can use this new method, because some dialects do >>>>>> their own calls, and they don't have a reference to the session or >>>>>> session >>>>>> factory from which we can get to the connection provider >>>>>> >>>>>> What are your thoughts? >>>>>> >>>>>> RP >>>>>> >>>>>> -- >>>>>> >>>>>> --- >>>>>> 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. >>>>>> >>>>> >>>>> -- >>>> >>>> --- >>>> 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. >>>> >>> >>> -- >> >> --- >> 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 >> <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- --- 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.
