Change in Session factory lifetime

[clydeseigle]

After upgrading from 5.3.1 to 5.4.9 I now get these errors.

'Cannot access a disposed object. Object name: 'Session factory with id 17fd39285abe4bd09f684f45b4f71eef'.'

It seems that something have changed in the management of the session factory lifetime or perhaps a default behavior has changed. Does anyone know what change is triggering this error?

Building the session factory is very expensive given the size of our data model so we need a means to reuse it and not create a new one each time. So if the change makes reusing the session factory impossible, what is the new way to efficient manage the session factory?

[oskarb]

As far as I know, creating and disposing the session factory is up to the application and not something NHibernate does for you.

[oskarb]

Try setting a breakpoint in SessionFactoryImpl.Close() or CloseAsync() and see what call path leads to it when it happens.

[clydeseigle]

That doesn't seem like the right commit number. That one is about Guid generation.

Also, what is it guarding against? It worked fine before. Seems like maybe it is triggering because of the IsClosed flag, not because the object is actually Disposed which would have caused a different error. Is there a good reference somewhere on how to reuse the session factory and not have it close if the way I was doing it is invalid for some reason?

[oskarb]

Sorry, the commit id was accidental, the point was the line in the release notes. I cleaned the link.

Either way, it references #3120.

Also, what is it guarding against?

Accidental use of a disposed object that previously may or may not have lead to confusing issues.

Seems like maybe it is triggering because of the IsClosed flag, not because the object is actually Disposed which would have caused a different error.

Looking at the code in SessionFactoryImpl, Close() and Dispose() are effectively the same thing.

Is there a good reference somewhere on how to reuse the session factory and not have it close if the way I was doing it is invalid for some reason?

Even after all these years, I think the basic rule about the session factory is what it says in quickstart 1.4 (https://nhibernate.info/doc/nhibernate-reference/quickstart.html#quickstart-playingwithcats), which is basically "you create it, you destroy it, it's expensive so typically you only want to do it once".

Creating and destroying the session factory is the responsibility of the application.

I really think you need to start looking at this from the PoV that something in your application is doing it.

• Some code trying to close a session accidentally calling close on the factory instead?
• Inappropriate DI registration so the IoC framework disposes it after some request or something like that?

With some logging configuration, you should be getting this log when it happens:

> log.Info("Closing");

It might help if you find the thread doing it I guess. Depending on if you also log something, it might be a clue. But setting a breakpoint as I suggested is probably more direct, if that's possible in your application.

[clydeseigle]

I did track down a place where the SessionFactory was being disposed and removed it; all works as expected now. Stange that it never appears to cause any issue.

Thanks for the help.

[oskarb]

Great!

Stange that it never appears to cause any issue.

Closing the session factory seems to largely be about destroying various caches and listeners - I suspect that it's possible to not use any of these features and therefore not notice any problem, at least not a clear problem. But now I'm just guessing.