Most of the transaction rework was about system transactions (transaction scopes). Regular transaction handling was not modified much. Using
> <entry key="transaction.factory_class" value=" > NHibernate.Transaction.AdoNetTransactionFactory"/> > as suggested on the other thread you point is valid only if you do not use system transactions. This transaction factory just ignores transaction scopes. Moreover, the system transaction handling of the default transaction factory is normally not involved when using regular transactions, so switching the transaction factory should not have much impacts on projects only using regular transactions, included on performances, while it is a bug source for other projects. Between the two transaction factories, the main difference when only using regular transactions is the fact the system aware one (and default one) will check on many occasions whether a system transaction is ongoing or not. This can be avoided by disabling the auto-join transaction feature, and explicitly asking the session to join the system transaction when you use one. https://nhibernate.info/doc/nhibernate-reference/transactions.html#transactions-scopes The rework on system transactions has introduced thread synchronization logic to avoid concurrency troubles occurring with distributed transactions. So far it seems to have fixed most of the issues NHibernate was having with distributed transaction scopes, so it is unlikely it will be undone. Maybe a "non-distributed system transaction" factory could be added for those not needing to support distributed transactions, and supposing the performance loss comes from these synchronizations. But things are very tricky there, a scope can be elevated to distributed on many unexpected cases. (Using ODBC data provider, or providers from SAP products (Sybase, Hana, ...) seems to always cause all scopes to be distributed; some other data-providers will go to distributed if opening, closing, reopening a connection in the scope, while others will not; ...) About the bag troubles, it is most likely pointing to a latent bug in the application code, causing results to duplicated with older releases. Maybe your application has some mechanism to compensate for this, but for upgrading, you will have to handle them by avoiding fetching more than one bag. Frequently a bag is used in mappings where really a set should be used instead, so adjusting the mappings could be one way of solving the trouble. Le dimanche 4 août 2019 18:12:47 UTC+2, Miles Thompson a écrit : > > I'm working on a project where I just upgraded NH 2.1 to 5.1. I wonder if > folks here feel that is 'too much' of an upgrade to bite off in one piece? > You gut reactions and first impressions very much appreciated. > > In the '*cons*' column its a large(ish) ten-year-old system I'm not all > that familiar with. On the *pros *side, you always want to be at the most > recent version and (thankfully due to some good architecture decisions ten > years ago) most of our NH persistence code is fairly well 'encapsulated' - > so I only need to look in a handful of projects to find the bits we need to > change. Also, I've successfully upgraded the code from an 'it builds' > perspective already it passed a super basic smoke test. I have been > carefully looking through the release notes. > > > However there are some more subtle regressions on further testing. The > biggest concerns I have found so far are: > > - We're doing this work for performance reasons and, so far, the shift to > 5.1 seems to drastically decrease performance rather than improve it. More > specifically, we made things more async at WCF level last week and this has > had a huge payoff - when done against 2.1 of the NH library. However when > we couple those async service changes with the upgrade to NH 5.1 all the > performance improvements disappear. Perhaps this is related to transaction > persistence as mentioned in this other thread > <https://groups.google.com/d/msg/nhusers/7C6z352w7ro/B4yqKvNfAAAJ> (I > can't wait to try) > > - After the upgrade, we are getting the old "Cannot simultaneously fetch > multiple bags" problems in a couple of places which looks kinda gnarly > > Basically, I'd really appreciate the opinions of anyone who has been > through this before? Is it worth pushing through with finding and fixing > any regressions or are we biting off months of work to finish a 2.1 -> 5.1 > upgrade and maybe better to just upgrade within 2.x? Or just to 3.x? > > Thanks in advance for any thoughts or opinions ! > > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nhusers/c56b0aec-2872-4ad3-9192-e9bcc956652c%40googlegroups.com.
