Hibernate:懒惰初始化与破坏的hashcode / equals难题

时间:2013-07-18 21:58:30

标签: java hibernate jpa hashcode lazy-initialization

我对JPA和Hibernate都很陌生(虽然我正在努力学习!)我正在努力解决一个我似乎无法找到一个简单解决方案的问题,所以现在就是这样。

我有一个看起来像下面的实体:

@Entity
@Table(name = "mytable1")
public class EntityOne {
  // surrogate key, database generated
  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  @Column(name = "id")
  private Long id;

  // business key
  @Column(name = "identifier", nullable = false, unique = true)
  private String identifier;

  @ManyToOne(fetch = FetchType.LAZY, cascade = CascadeType.REFRESH)
  @JoinColumn(name = "twoId", nullable = false)
  private EntityTwo two;

  @OneToMany(mappedBy = "entityOne", fetch = FetchType.EAGER, 
    cascade = {CascadeType.ALL}, orphanRemoval = true)
  private Set<EntityThree> resources = new HashSet<>();

  // getters/setters omitted

  @Override
  public int hashCode() {
    // the business key should always be defined (through constructor/query)
    // if this is null the class violates the general hashcode contract 
    // that the integer value returned must always be the same
    Assert.notNull(identifier);
    // a dirty alternative would be:
    // if(identifier==null) return 0;
    return identifier.hashCode();
  }

  @Override
  public boolean equals(Object o) {
    return o instanceof ResourceGroup 
      && ((ResourceGroup) o).identifier.equals(identifier);
  }
}

我的项目是使用Spring JPA设置的,所以我将CrudRepository<EntityOne,Long>注入到一个具有一些@Transactional方法的Service类中,并分别扫描我的域/服务包以获取JPA和事务。

其中一个服务方法调用存储库的findAll()方法并返回EntityOne个列表。一切正常,除非我尝试访问two的getter,这显然会抛出:

org.hibernate.LazyInitializationException: could not initialize proxy - no Session

我认为初始化这个对象可能很有用,所以我把抓取类型从懒惰切换到急切。但是,如果我这样做,我会得到以下结果:

java.lang.IllegalArgumentException: [Assertion failed] - this argument is required; it must not be null
    at org.springframework.util.Assert.notNull(Assert.java:112)
    at org.springframework.util.Assert.notNull(Assert.java:123)
    at my.pkg.domain.EntityOne.hashCode(ResourceGroup.java:74)
    at java.util.HashMap.hash(HashMap.java:351)
    at java.util.HashMap.put(HashMap.java:471)
    at java.util.HashSet.add(HashSet.java:217)
    at java.util.AbstractCollection.addAll(AbstractCollection.java:334)
    at org.hibernate.collection.internal.PersistentSet.endRead(PersistentSet.java:346)
    at org.hibernate.engine.loading.internal.CollectionLoadContext.endLoadingCollection(CollectionLoadContext.java:243)
    at org.hibernate.engine.loading.internal.CollectionLoadContext.endLoadingCollections(CollectionLoadContext.java:233)
    at org.hibernate.engine.loading.internal.CollectionLoadContext.endLoadingCollections(CollectionLoadContext.java:209)
    at org.hibernate.loader.Loader.endCollectionLoad(Loader.java:1149)
//...

我简要地看了一下Hibernate的源代码,看起来它试图将我的EntityOne对象放在之前的业务键初始化之前。我的解释是否正确?有没有解决的办法?我做了一件非常愚蠢的事吗?

感谢您的帮助

编辑:我只想澄清一点,我在这里想要了解的是最佳做法是针对JPA和Hibernate 的具体。如果这是一个简单的POJO我可以使标识符字段最终(我实际上将使整个类不可变)并且是安全的。我不能这样做,因为我正在使用JPA。所以问题:你是否违反了hashCode合同以及以何种方式? Hibernate如何处理这种违规行为? JPA推荐的一般方法是什么?我应该完全摆脱基于散列的集合并改为使用列表吗?

乔瓦尼

3 个答案:

答案 0 :(得分:8)

不,你没有做任何愚蠢的事。在JPA实体上实现equals和hashCode是一个非常激烈的问题debate,我所知道的所有方法都有明显的缺点。你没有明显的,微不足道的解决方案。

然而,你已经找到了一个由于某种原因没有进行过多讨论的案例。使用业务密钥的hibernate wiki recommends和第398页的“Java Persistence with Hibernate”(Bauer / King,2007,被广泛认为是标准的Hibernate参考工作)建议使用相同的东西。但在某些情况下,正如您所观察到的,Hibernate可以在其字段初始化之前将实体添加到Set中,因此基于业务键的hashCode不起作用,就像您指出的那样。有关此案例的讨论,请参阅Hibernate问题HHH-3799。在Hibernate源代码中有一个预期失败的test case来证明这个问题,在2010年添加,因此至少有一个Hibernate开发人员认为它是一个bug并且想要修复它,但是还没有自2010年以来的任何活动。请考虑对该问题进行投票。

您可能考虑的一个解决方案是扩展会话的范围,以便您对实体的所有访问都在同一会话中进行。然后你可以让你的Set<EntityThree>变得懒惰而不是渴望获取,你将避免在HHH-3799中出现急切的问题。我所研究的大多数应用程序只能在分离状态下少量使用对象。听起来你正在加载你的实体,然后在会话结束后使用它一段时间;这是我建议反对的模式。如果您正在编写Web应用程序,请参阅“在视图中打开会话”模式和Spring的OpenSessionInViewFilter,以获取有关如何执行此操作的建议。

顺便说一下,我喜欢在未初始化业务键时抛出异常的方式;这样你就可以快速发现编码错误。我们的应用程序有一个令人讨厌的错误,因为HHH-3799,如果我们使用了你的非空断言,我们可能已经开发了它。

答案 1 :(得分:0)

您的解释是正确的。首先使用您的hashCode()字段为您的equals()id代码 - 您正在告诉Hibernate这是您的身份。

第二步,实施正确的hashCode()equals(),以免您将来遇到麻烦。如果你谷歌它有很多资源。 Here是此网站上的一个

答案 2 :(得分:0)

我相信我实际上找到了一种方法来使这项工作更好一些,即强制Hibernate(或任何JPA提供者)在将对象粘贴到集合之前使密钥可用。在这种情况下,对象将被正确初始化,我们可以确保业务键不会为空。

例如,以下是类EntityTwo必须看的方式:

@Entity
@Table(name = "mytable2")
public class EntityTwo {
  // other code omitted ...
  @OneToMany(mappedBy = "entityTwo", fetch = FetchType.EAGER, 
    cascade = {CascadeType.ALL}, orphanRemoval = true)
  @MapKey(name = "identifier")
  private Map<String, EntityOne> entityOnes = new HashMap<>();
}

我没有测试过这个特定的代码,但我有其他工作示例,它应该可以正常工作JPA docs。在这种情况下,JPA提供程序被逼走:它必须知道identifier的值才能将对象放入集合中。此外,甚至没有调用对象的hashCodeequals,因为映射是由JPA提供者显式处理的。

在这种情况下,明确强制工具了解事物的建模方式并相互关联会带来很大的好处。