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.
