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 <[email protected]>: > 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 <[email protected]>: >> >> 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. >>> EnsureConnectionIsOpen >>> - 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 [email protected]. >>> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
