2014-09-03 1:16 GMT+02:00 Ricardo Peres <rjpe...@gmail.com>: > 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. > 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.
