将数据从休眠层提取到另一层的最佳方法是什么？

发布于 2024-07-21 16:15:23 字数 250 浏览 2 评论 0 原文

正如我之前的帖子可以证明的那样，我正在将内存中的网络缓存性能改造为曾经完全休眠的场景。在执行此操作时，我遇到了处理代理对象并需要重新附加到会话的问题，但在执行此操作时我还想保持可事务性。将复杂逻辑移出休眠层的最佳实践是什么？我现在刚刚“完全”进入冬眠状态，所以这是一次相当可恨的经历。

任何从事过此类数据移动工作的人都可以详细说明您如何克服事务问题、处理代理对象等吗？我现在只是在寻找一般资源，因为我正在努力游泳。

谢谢。

原文

分享到QQ

分享到微博

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

发布评论

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

亢潮 2024-07-28 16:15:23

您需要决定两件事：

您的会话管理策略
您关联的获取策略

有一个很好的 Gavin King 的帖子，解释了处理会话的一些选项（该帖子是关于性能的，但通常也适用）。

至于获取，需要考虑的一件事是增加 Hibernate 层提供的原语数量。例如，假设您有一个与 Bar 具有 1-N 关系的实体 Foo，在某些情况下您只需要 Foo 对象，但在其他情况下您需要 Foos 和子 Bar 对象。您可以将它们表示为对 Hibernate 层的单独调用。

class HibernateLayer {
    public List<Foo> findFoo(String someCriteria) {
        Query q = new Query("from Foo f where f.someCriteria = :1");
        //...
    }

    public List<Foo> findFooWithBars(String someCriteria) {
        Query q = new Query("from Foo f left join fetch Bar b where f.someCriteria = :1");
        //...
    }

这有 2 个好处，1 你不会处理延迟加载的代理对象，你将拥有所需的所有数据，并且它会执行得更好，因为生成的 SQL 将更适合情况。然而，它有一个缺点，即在调用 Hibernate 层之前您需要知道是否需要更深层次的数据。为了确保您的数据保持一致（事务的主要目的），请确保使用至少乐观锁定。

You need to decide on 2 things:

Your session management strategy
Your associated fetching strategy

There is good post by Gavin King that explains some of the options for handling sessions (the post is about performance, but is generally applicable too).

As for fetching, one thing to consider is increasing the number of primitives made available by your Hibernate layer. E.g. imagine you have a entity Foo that has a 1-N relationship to Bar and some circumstances you need just the Foo objects, but in others you need both the Foos and the child Bar objects. You could those represented as separate calls to the Hibernate layer.

class HibernateLayer {
    public List<Foo> findFoo(String someCriteria) {
        Query q = new Query("from Foo f where f.someCriteria = :1");
        //...
    }

    public List<Foo> findFooWithBars(String someCriteria) {
        Query q = new Query("from Foo f left join fetch Bar b where f.someCriteria = :1");
        //...
    }

This has 2 benefits, 1 you won't deal with lazy loaded proxy objects, you'll have all the data that you need and it will perform better as the SQL generated will be more appropriate to the situation. However it will have the drawback that you will need to know before calling the Hibernate layer whether or not you will need the deeper level of data. To ensure that your data remains consistent (the main purpose of transactions) make sure you use optimistic locking at the very least.

回复收藏 0 原文