It may seem to be a good idea to have a mandatory transaction within a session, but you are forgetting that a session may use many transactions, which makes it difficult to force a transaction creation within a sesssion. I.E. when you commit a transaction and and the session is not yet closed do you automatically create another transaction, just in case the session is going to do more transactional work?
I think many of the problems are a result of changes from v1.2 to 2.x where it was recognized that a transaction was necessary for any read or write activity with the database. However, there probably is a substantial body of applications started in v1.2 that were upgraded to v2.x where the upgrade to wrap all reads did not happen. I don't think this can easily be fixed by changing the session semantics. John Davidson On Thu, May 6, 2010 at 8:42 AM, Davy Brion <[email protected]> wrote: > yup, i feel the same way > > > On Thu, May 6, 2010 at 2:37 PM, Richard Brown <[email protected]>wrote: > >> IMHO, if the usage is not allowed, we should change the API to disallow >> session without a tx. If it is allowed we should fix it. >> >> Sent from my Android phone. >> >> On 6 May 2010 13:19, "Davy Brion" <[email protected]> wrote: >> >> Hey guys, >> >> i just ran into a weird issue with leaking connections due to using a >> TransactionScope without using an NH transaction... i've described the >> problem here: >> >> http://davybrion.com/blog/2010/05/avoiding-leaking-connections-with-nhibernate-and-transactionscope/ >> >> the thing is: is this a bug in NH or not? I mean... it might be due to bad >> usage, but if the usage scenario is bad, then NHibernate should probably >> warn against it instead of playing along and failing silently in some >> cases... >> >> thoughts? >> >> >
