NHibernate 会话的生命周期应该是多少? [英] What should be the lifetime of an NHibernate session?

问题描述

我是 NHibernate 的新手，并且在过早关闭会话时遇到了一些问题.我通过重用会话而不是为每个事务打开一个会话来临时解决了这个问题.但是，我的印象是每次需要时打开会话是会话生命周期管理的推荐方法.不?

I'm new to NHibernate, and have seen some issues when closing sessions prematurely. I've solved this temporarily by reusing sessions instead of opening a session per transaction. However, I was under the impression that opening sessions each time you need them was the recommended approach for session lifetime management. No?

所以；处理会话的推荐方式是什么?他们的一生应该是怎样的?一期公关交易?一个单例会话来处理所有事情?要不然是啥?

So; what is the recommended way of handling sessions? What should their lifetime be? One session pr transaction? One singleton session to handle everything? Or what?

请注意，我的应用程序架构是一个桌面应用程序，它与服务器端服务进行通信，使用 NHibernate + Fluent 进行所有数据库处理.(如果这有什么不同...)

Note that my application architecture is a desktop application communicating with a server side service, which is what does all the Database handling, using NHibernate + Fluent. (If this makes any difference...)

推荐答案

您需要一个会话管理策略，使您的应用程序能够有效运行并利用 NHibernate 为您提供的功能 - 最显着的是缓存和延迟加载.

You want a session management strategy that allows your app to function effectively and take advantage of the things that NHibernate gives you - most notably caching and lazy loading.

创建会话是一个成本低廉的过程，只需要很少的前期 RAM 或 CPU，因此您不必担心保存或重用会话(实际上，重用它们可能会导致一些令人讨厌和意外的副作用——效果).会话工厂是昂贵的东西，应该在应用启动时构建一次并且只构建一次.

Creating sessions is an inexpensive process and requires little up-front RAM or CPU, so you shouldn't worry about conserving or re-using sessions (indeed, re-using them can lead to some nasty and un-anticipated side-effects). The session factory is the expensive thing and should be built once and only once at app startup.

经验法则是:会话生存期需要足够长，以便在会话结束后不会有持久化的对象在范围内徘徊.

The rule of thumb is this: the session lifetime needs to be long enough that you don't have persisted objects hanging around in scope after the session ends.

会话结束后，您从该会话获得的对象的所有更改跟踪都会停止，因此除非您有意将该对象重新附加到新会话，否则不会保存这些更改.因此，只要您从中获取的对象将存在，会话就应该存在.在 Web 应用程序中，这通常意味着每个请求都有一个会话；在 WinForms 中，每个表单都有一个会话.

Once the session ends, all change tracking for objects you got from that session stops, so those changes don't get saved unless you deliberately re-attach that object to a new session. The session should therefore be around for as long as the objects you fetch from it are going to exist. In a Web app, that generally means a session for each request; in WinForms, a session for each form.

在您的情况下，如果服务(我假设它作为 Windows 服务运行)执行 NHibernate 工作，您可能希望考虑为来自消费桌面应用程序的每个新请求创建一个会话，并在该请求得到服务后处理它.不知道你的服务是如何运行的，以及桌面应用程序使用什么机制来与之对话(远程?WCF?普通的旧 SOAP?)我真的不能更具体.

In your case, with a service (I assume it's running as a Windows service) doing the NHibernate work, you might wish to consider having a session created for each new request from the consuming desktop app, and disposing it when that request has been serviced. Not knowing exactly how your service runs and what mechanism the desktop app uses to talk to it (remoting? WCF? Plain old SOAP?) I can't really be more specific.

(这个一般规则有一些例外 - 假设您有一组持久化对象代表其他代码将引用但不会更改的共享资源，您可以在应用程序启动时预先加载这些并保留它们从此断开连接.)

(There are some exceptions to this general rule - suppose you have a set of persisted objects that represent a shared resource to which other code will refer but not change, you can load these up-front at app-start and leave them disconnected from then on.)

如果你发现在这样的策略下性能很慢，那可能是你只是和数据库说话太多，你的对象图很复杂；在这种情况下查看二级缓存.

If you find performance sluggish under such a strategy, it may be that you're just talking to the database too much and your object graph is complex; look at second-level caching in this case.

这篇关于NHibernate 会话的生命周期应该是多少?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！