It'd be really nice if transaction actually started before first query 
instead just first BeginTransaction call. Is it possible to achieve such 
behavior without NHibernate code change? Maybe there is a proper extension 
point for it?

пятница, 20 марта 2015 г., 19:47:36 UTC+2 пользователь Joel Hervén написал:
>
> That´s good to know. I have taken some time trying to look at the 
> NHibernate-core to determine how hard it would be implementing a change 
> like this, my conclusion at this point is that it will require quite some 
> changes, at least my test modifications didn´t end up with the desired 
> result.Guess my best chance is to hope for any experienced NHibernate 
> developer to see a value in this possibility, but with NHibernate being 
> around for soon 10(?) years I guess there isn´t much demand for this 
> feature. Which I feel is a bit strange as I believe this in most cases 
> should be the preferred standard behavior when working with a cache, at 
> least that's how you normally do when not using an ORM, you check your 
> cache first before starting a transaction and query the database. 
>
> Den onsdag 18 februari 2015 kl. 14:47:31 UTC+1 skrev Oskar Berggren:
>>
>> 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.

Reply via email to