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