I'm pretty sure this is intended behaviour. In either case I've never really thought about it. Originally, a connection would be claimed already when the session was created, but that was later delayed until the transaction was started.
In some of my applications I don't allocate the session until something tries to use it, but that wouldn't help with your second level cache case. I wonder if there might be cases (isolation levels? distributed transactions?) where the timing of the BEGIN is important even though actual queries comes later. To change the behaviour, someone should analyse this and come up with an implementation. If it's useful, it could perhaps be added as a non-default optional mode. /Oskar 2015-02-18 1:04 GMT+00:00 James Nail <[email protected]>: > This appears to be happening for me as well, with Sql Server 2012, and NH > version 4.0.2.4000. > I also had the same understanding about the beginTransaction behavior, > although I'm having trouble finding where I read about this originally. > > Can anyone shed some light here? > > > On Friday, February 6, 2015 at 10:31:11 AM UTC-5, Joel Hervén wrote: >> >> In an attempt to limit the number of connections that Nhibernate opens >> against our database I have run into a problem regarding the start of a >> transaction. >> >> We run Nhibernate 3.3 in a web-application, session-factory is created at >> application start up and on a new request we open a new session and starts >> a transaction. When the request ends we commit/rollback the transaction and >> disposes the session. My understanding was that calling BeginTransaction >> wouldn´t really start a transaction until it had something to run against >> the database, unfortunately that isn´t the case. Looking at the mysql log i >> can see that when BeginTransaction is called "SET SESSION TRANSACTION.... >> BEGIN" is directly sent to the database. >> >> I did a little test with second level cache enabled >> 1. Load an entity to get it into the cache >> 2. Create 100 threads and let them all request the same object. >> >> The result was 100 open connections against the database, one meaningful >> query against the db that loaded the actual object and 100 queries that >> more or less was just begin/commit without any actual queries. This seems >> very inefficient, everything is in our cache so the database shouldn´t need >> to be bothered at all except for the first query. >> >> Is this the intended behavior? If yes do you have any recommendations to >> avoid this bottleneck? >> > -- > 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 post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/nhusers. > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers. For more options, visit https://groups.google.com/d/optout.
