我正在使用一个ScrollableResults
对象从表中滚动大约 500,000 到 1,000,000 行。在滚动时,我使用每次迭代的结果实体创建一个不同的实体,并用于session.save()
持久化该对象。下面是示例代码,其中真正的代码更复杂,但本质上是做同样的事情。
Session = getSessionFactory().openSession();
Transaction tx = session.beginTransaction();
ScrollableResults results = session.createQuery("from Foo_Table f join f.bars b")
.scroll(ScrollMode.FORWARD_ONLY);
int i = 0;
while(results.next())
{
Foo foo = (Foo) results.get(0);
Bar bar = new Baz(foo);
bar.setFoo(foo);
session.save(bar)
if(i % 50 == 0)
{
session.flush();
session.clear();
}
}
tx.commit();
session.close();
重要实体:
@Entity
@Table(name = "FOO_TABLE")
public class Foo_Entity implements Serializable {
@Id
@Column(name = "Foo_ID", nullable=false)
private String id;
@OneToMany(fetch = FetchType.EAGER, //FetchType.LAZY fixes the slow down
mappedBy = "fooParent", cascade = CascadeType.ALL)
private Set<Bar> bar_entities = new HashSet<>(0);
}
@Entity
@Table(name = "BAR_TABLE")
public class Bar_Entity implements Serializable {
@Id
@GeneratedValue
@Column(name="Id")
private Long id;
@ManyToOne
@JoinColumn(name="foo_pk")
private Foo fooParent;
// setFoo, getFoo...
}
当我为这个事务计时时,运行时间从每 500 次迭代大约 100 毫秒开始,但在大约 20,000 次迭代后逐渐上升到每 500 次迭代几秒。因此,该事务的性能极差。唯一需要花费时间的代码行是results.next()
,它的执行时间会越来越长。
如果我将 Foo 中 Bar 实体的获取类型从渴望更改为惰性,则问题得到解决。我不明白为什么对尚未填充的集合使用渴望获取类型会导致滚动包含关系的实体出现问题。该集合确实在 session.flush() 上滚动期间被填充,但在我的场景中,该集合通常只填充一到两个元素,这就是为什么我更喜欢这种获取类型作为急切的原因。
有谁知道为什么这种特殊情况会发生这种减速?
请注意,这个问题是在我意识到更改 fetch 类型解决了问题之前首次发布的,所以问题现在已经从“我该如何解决这个问题”转移到“为什么这是一个问题?”