(流畅)NHibernate 处理冗长事务的进度事件?

发布于 2024-12-18 08:37:11 字数 518 浏览 3 评论 0原文

我们已经连接了 ISaveOrUpdateEventListener 事件,并希望我们可以将其与一个相当大的模型的保存遍历期间访问的每个节点的进度条更新联系起来,但是该事件仅在保存操作开始时触发一次(仅在该节点上) Save() 是在其上启动的,而不是在任何子节点上)。

还有其他更适合聆听的事件吗?

我们还尝试通过自己进行遍历来分解(分层模型的)保存操作,但这似乎会进一步降低性能。

也许我们正在尝试解决 FNH 不适合用来解决的问题。我们对此还很陌生。

我们还使用 SqlBulkCopy 设置了替代解决方案,如其他地方所推荐的。

我们已经看到这样的评论:FNH 主要适用于较小的事务 (OLTP),而不是我们的问题所束缚的详尽模型类型(大量数据的信号处理)。

背景:

我们正在尝试在一个更大的数据库项目上使用 Fluent NHibernate,该项目的数据来自相当复杂的实时分析(高频、多个输入信号、长实验时间等)。在我们构建的原型中,我们看到目前的等待时间非常可怕,并且需要挂钩某种可靠的进度指示器。

We've hooked up the ISaveOrUpdateEventListener event and hoped we could tie it to a progress bar update for each node being visited during the save traversal of a pretty big model, BUT the event only fires once when the save operations starts (only on the node on which the Save( ) was inititated and not on any subnodes).

Are there any other events that are more appropriate to listen to for this?

We've also tried breaking up the save operation (of a hierarchical model) by doing the traversal ourselves, but that seems to degrade the performance even further.

Perhaps we're trying to solve a problem for which FNH wasn't aimed to be used. We're new to it.

We've also set up an alternative solution using SqlBulkCopy, as recommended elsewhere.

We've seen the comments that FNH is primarily supposed for smaller transactions (OLTP) and not the type of exhaustive model we're bound to by our problem (signal processing of huge data volumes).

Background:

We're trying to use Fluent NHibernate on a larger database project with data gathered from fairly complex real time analysis (high frequency, multiple input signals, long experiment times etc). In a prototype we've built we see pretty scary wait times for the moment, and need to hook in some sort of reliable progress indicator.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

初见你 2024-12-25 08:37:11

是的,现在已确认 - 正如我在上面的评论中提到的。对此的一种(可能的)解决方案是简单地关闭 Cascades 并手动进行模型遍历并执行显式的 Save() 调用。

这是可行的,尽管它不像处理事件那么简洁。尽管如此,考虑到 NHibernate 的真正设计,我敢打赌肯定在某个地方有一个事件可以被拦截 - 问题只是在什么名称下。 ...我敢打赌这里有人知道更多。

另外,为了提高性能,我们使用了无状态会话,使用不同的批量大小进行实验,并定期/显式调用 Flush() 和 Clear()。有关更多详细信息,请参阅以下文章:

http:// /davybrion.com/blog/2008/10/bulk-data-operations-with-nhibernates-stateless-sessions/

http://ideas-net.blogspot.com/2009/03 /nhibernate-update-performance-issue.html

希望这有帮助。

Yes, now confirmed - as mentioned in my comment above. One (possible) solution to this is to simply turn of Cascades and do the model traversal manually and do explicit Save( ) calls.

This works, although it's not as neat as just handling an event. Still, given the genuin design of NHibernate, I bet there's certainly an event somewhere that could be intercepted - the question is just under what name. ... I bet someone on here knows more.

Also to improve performance we used a Stateless Session, experiemented with differnet batch size, and periodically/explicitly call Flush() and Clear(). See articles below for further details:

http://davybrion.com/blog/2008/10/bulk-data-operations-with-nhibernates-stateless-sessions/

http://ideas-net.blogspot.com/2009/03/nhibernate-update-performance-issue.html

Hope this helps.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文