Understanding how NH handles database connections

[Joe]

I am trying to understand how NH handles the actual ADO.NET
connection.

For example, when I request ISession.Connection, I get an OPEN
IDbConnection. The connection appears to stay open until
ISession.Close is called.

Is this the expected behavior? I was trying to use the ADO connection
provided by NH and was surprised to find it already opened. I was
expecting to have to open and close the connection.

If I need to use the connection from ISession, should I not worry
about opening and closing it?

Thanks,
Joe

[Roger Kratz]

You can open/close the connection using session.Disconnect()/Reconnect() which is recommended if you hang on to the session for a while.

If you use long lived session I agree that it might feel better if the created session was closed (disconnected).to start with. I guess the choosen path is chosen due to the "normal handling" of session which is short lived.

________________________________________
Från: nhu...@googlegroups.com [nhu...@googlegroups.com] för Joe [jyoun...@gmail.com]
Skickat: den 1 oktober 2008 23:04
Till: nhusers
Ämne: [nhusers] Understanding how NH handles database connections

[Fabio Maulo]

If you are using NH session API NH open & close the connection ASAP.

If you get the connection from the session NH give you always an opened connection and you must take care about what you are doing before and after get that connection, before and after begin transaction with that connection and before and after open a DataReader with that connection.

In practices is better if you use session.CreateSQLQuery or IQuery.ExecuteUpdate instead use the connection of the session.

2008/10/1 Joe <jyoun...@gmail.com>

--
Fabio Maulo

[Fabio Maulo]

Disconnect/Reconnect are pretty deprecated..

If you are outside a transaction the connection is released after command execution (depending on command batcher too).

If you are inside a transaction NH release the connection after transaction complete.

If you open a session using your connection NH give you the responsibility to do what you want with it.

2008/10/1 Roger Kratz <Roger...@teleopti.com>

--
Fabio Maulo

[Roger Kratz]

Hmm... I must miss something or maybe I misunderstand your but... When I commit an ITransaction, the db connection is still open.



________________________________
Från: nhu...@googlegroups.com [nhu...@googlegroups.com] för Fabio Maulo [fabio...@gmail.com]
Skickat: den 1 oktober 2008 23:38
Till: nhu...@googlegroups.com
Ämne: [nhusers] Re: SV: [nhusers] Understanding how NH handles database connections

Disconnect/Reconnect are pretty deprecated..
If you are outside a transaction the connection is released after command execution (depending on command batcher too).
If you are inside a transaction NH release the connection after transaction complete.

If you open a session using your connection NH give you the responsibility to do what you want with it.

2008/10/1 Roger Kratz <Roger...@teleopti.com<mailto:Roger...@teleopti.com>>

You can open/close the connection using session.Disconnect()/Reconnect() which is recommended if you hang on to the session for a while.

If you use long lived session I agree that it might feel better if the created session was closed (disconnected).to start with. I guess the choosen path is chosen due to the "normal handling" of session which is short lived.

________________________________________

Från: nhu...@googlegroups.com<mailto:nhu...@googlegroups.com> [nhu...@googlegroups.com<mailto:nhu...@googlegroups.com>] f&#246;r Joe [jyoun...@gmail.com<mailto:jyoun...@gmail.com>]

Skickat: den 1 oktober 2008 23:04
Till: nhusers
Ämne: [nhusers] Understanding how NH handles database connections

I am trying to understand how NH handles the actual ADO.NET<http://ADO.NET>

[Fabio Maulo]

Are you sure ?

The default connection release mode is "auto" that mean AfterTransaction...

mmm I must improve the logging of connection manager to check it.

--
Fabio Maulo

[Fabio Maulo]

and more... We must remove the exception for "after_statement" (aggressive release mode) because in theory I port the necessary code, to support it, some moths ago.

mmm probably I'm forgetting something else... :~ why the throw of the exception still there ?

ok... work for this weekend...

2008/10/1 Fabio Maulo <fabio...@gmail.com>

--
Fabio Maulo

[Fabio Maulo]

Ah... thanks Roger to remember me this thing.

--
Fabio Maulo

[Roger Kratz]

I double checked it, asserting in some tests in the trunk of nh tests to verify that nothing is wrong in my apps config and/or unitofwork impl. And yes - it seems that I'm correct.

...but please don't believe me too much. Late here in Sweden and I worked far too many hours. My eyes can fool me...

/Roger

________________________________
Från: nhu...@googlegroups.com [nhu...@googlegroups.com] för Fabio Maulo [fabio...@gmail.com]

Skickat: den 2 oktober 2008 00:01
Till: nhu...@googlegroups.com
Ämne: [nhusers] Re: SV: [nhusers] Re: SV: [nhusers] Understanding how NH handles database connections

Are you sure ?
The default connection release mode is "auto" that mean AfterTransaction...
mmm I must improve the logging of connection manager to check it.

2008/10/1 Roger Kratz <Roger...@teleopti.com<mailto:Roger...@teleopti.com>>

Hmm... I must miss something or maybe I misunderstand your but... When I commit an ITransaction, the db connection is still open.



________________________________

Från: nhu...@googlegroups.com<mailto:nhu...@googlegroups.com> [nhu...@googlegroups.com<mailto:nhu...@googlegroups.com>] för Fabio Maulo [fabio...@gmail.com<mailto:fabio...@gmail.com>]

Skickat: den 1 oktober 2008 23:38

Till: nhu...@googlegroups.com<mailto:nhu...@googlegroups.com>

Ämne: [nhusers] Re: SV: [nhusers] Understanding how NH handles database connections

Disconnect/Reconnect are pretty deprecated..
If you are outside a transaction the connection is released after command execution (depending on command batcher too).
If you are inside a transaction NH release the connection after transaction complete.

If you open a session using your connection NH give you the responsibility to do what you want with it.

2008/10/1 Roger Kratz <Roger...@teleopti.com<mailto:Roger...@teleopti.com><mailto:Roger...@teleopti.com<mailto:Roger...@teleopti.com>>>

You can open/close the connection using session.Disconnect()/Reconnect() which is recommended if you hang on to the session for a while.

If you use long lived session I agree that it might feel better if the created session was closed (disconnected).to start with. I guess the choosen path is chosen due to the "normal handling" of session which is short lived.

________________________________________

Från: nhu...@googlegroups.com<mailto:nhu...@googlegroups.com><mailto:nhu...@googlegroups.com<mailto:nhu...@googlegroups.com>> [nhu...@googlegroups.com<mailto:nhu...@googlegroups.com><mailto:nhu...@googlegroups.com<mailto:nhu...@googlegroups.com>>] f&#246;r Joe [jyoun...@gmail.com<mailto:jyoun...@gmail.com><mailto:jyoun...@gmail.com<mailto:jyoun...@gmail.com>>]

Skickat: den 1 oktober 2008 23:04
Till: nhusers
Ämne: [nhusers] Understanding how NH handles database connections

I am trying to understand how NH handles the actual ADO.NET<http://ADO.NET><http://ADO.NET>

[Joe]

I did not think to use session.CreateSQLQuery, will do that instead
and let NH worry about managing the connection. :D

Thanks!
Joe

On Oct 1, 4:32 pm, "Fabio Maulo" <fabioma...@gmail.com> wrote:
> If you are using NH session API NH open & close the connection ASAP.If you

> get the connection from the session NH give you always an opened connection
> and you must take care about what you are doing before and after get that
> connection, before and after begin transaction with that connection and
> before and after open a DataReader with that connection.
> In practices is better if you use session.CreateSQLQuery or
> IQuery.ExecuteUpdate instead use the connection of the session.
>

> 2008/10/1 Joe <jyoung1...@gmail.com>

[Roger Kratz]

Fabio,

Regarding this one about connections... I had a quick look at this and the thing that sort of fooled me was the fact that (using ConnectionReleaseMode.AfterTransaction) not only was the connection closed but also the connection was set to null so when touching the connection prop of ISession after a transaction is committed, a _new_ connection is created. Neither was session's closed field set. My asserts therefore fooled me.

The good thing is that I now understand what you talked about should happen :) The bad thing is... Is this really good? Wouldn't it be better if the old connection still was alive but closed? Would be more clear to the user if this handling would be more explicit by the user I think....

Is current impl by design or a bug? (I'm talking about connection==null, connectionmanager row 185).

/Roger

[Fabio Maulo]

Ah... thank to verify it.

It working as expected... BTW the work for the weekend stay there because I must check the aggressive-release-mode.

Why, in your opinion, set the connection to null is a problem ?

2008/10/3 Roger Kratz <Roger...@teleopti.com>

--
Fabio Maulo

[Roger Kratz]

”A problem” might be a too strong word but… It fooled me. I didn’t know that the connection was closed when a transaction was committed, because…

 

using(ISession session = OpenSession())

{

   using(ITransaction tx = session.BeginTransaction())

   {

      [...]

      tx.Commit();

   }

   Assert.IsFalse(session.IsConnected);  

   Assert.AreEqual(ConnectionState.Closed, session.Connection.State);

}

 

…none of these asserts are ok. The first one fails due to the “ownConnection” field is true, the second assert fails due to this “implicit” instantiation of a new connection.

 

But never mind… Now I know what I didn’t understand J

[Fabio Maulo]

We have some pending task regarding ConnectionManager & TransactionManager...

I would like to have a full integration with ambient transactions but using the same architecture of Hb (AdoContext and others stuff... long to explain).

BTW the task must be completed before release NH2.1 (this time, it is not an option).

2008/10/3 Roger Kratz <Roger...@teleopti.com>

--
Fabio Maulo