问题描述
|
我在春季设置了一个TX建议，以围绕我的Service方法包装事务。这么说，在我的批处理类中，我调用了一个服务方法来加载对象列表并将其返回给我的批处理类。然后在批处理类中，我调用一个服务方法来处理每个对象。但是，如果该服务方法尝试访问对象的延迟加载属性，则我将收到延迟加载异常，因为该对象列表是通过不同的休眠会话加载的。
因此，解决该问题的最佳方法是-批处理类仅调用服务以加载这些对象的所有ID（长值）-然后将其传递给服务方法，该方法将从然后通过ID对DB进行处理。
有这个想法吗？
我遇到的另一个问题是，如果这些对象中的每个对象彼此独立，那么我是否应该一次不持久地保留每个对象，而不是一次或批量地持久化所有对象。如果有5000条记录，则似乎应用程序在调用save / update / insert时会减慢很多速度，因为它仍在Hibernate Session中完成所有内存操作。但是，如果我改为保存/更新/插入每条记录（一次处理一个ID），然后在处理完该对象后再提交到下一个对象，则提交该记录，这似乎可以大大提高速度。另外，如果我进行批量处理，比如说每200个甚至一次全部进行5000次，如果一条记录无法插入/更新并出现错误，则任何内容都不会持久化，并且一切都会回滚。
处理此类事情的最佳实践是什么？好像真的很普通。谢谢
解决方法
首先，Spring / Hibernate并不是真正用于批处理。相反，请检查Talend或Pentaho（如果您是开源的），或任何种类繁多（大量！）的商业工具。这些工具中的任何一个都可以用来自动生成可以完全满足您需要的Java代码块（包括插入优化，优雅的错误处理等）。
好的，假设您确实要让Spring / Hibernate进行批处理。您有几个不同的问题-首先，Hibernate会话生命周期意味着加载的对象希望与实时会话相关联。您可以使用会话flush（）强制将更改传播到数据库。会话close（）将清除所有内容。只能很困难地将已经加载的对象重新附加到新的会话（通常，重新加载对象比较容易）。如果不关闭（）/ flush（）会话，最终（可能）会耗尽内存。您可以通过添加一个Hibernate 2级缓存来解决此问题，但这只会使事情变得更加复杂并使它变慢。
没有真正的理由不只是在独立的Hibernate会话中进行每次插入（打开，执行工作，关闭）。它不会像专用工具那样快，但是它很简单，可以很好地工作，并且或多或少都与您得到的一样好。
, 关于批处理要求，请使用Spring批处理链接
这提供了所需的所有必要的配料设备。
关于对象加载问题，
所以解决这个问题的方法可能不是
最好的是-批次类
只是调用服务来加载所有
这些对象的ID（长值）-
然后我们将此ID传递给服务
加载该对象的方法
从数据库通过ID，然后执行
处理。
似乎是正确的。