对象和关系型数据库之间存在着根本不同, ORM（对象/关系映射）试图把对象映射到关系型数据库的表结构上，从而简化存储对象到数据库及从数据库中恢复对象的复杂性，让操作数据库就像操作对象一样简单。Hibernate估计是众多ORM框架中最成熟的了，但是在处理类的继承关系时还是会有一些问题。

延迟加载与继承
先看如下的代码, 演示这一映射关系：

@Entity
@Table(name = "a")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(
		name = "disc", 
		columnDefinition = "varchar(4)", 
		discriminatorType = DiscriminatorType.STRING)
public abstract class A {
 @Id
 private int oid;
 private String name;
}
 
@Entity
@DiscriminatorValue("b")
public class B extends A {
private String age;
}
 
@Entity
@DiscriminatorValue("c")
public class C extends B {
private String sex;
}
 
@Entity
@Table(name = "d")
public class D {
  @Id
  private int oid;
  @ManyToOne(fetch = FetchType.LAZY)
  private A a;
  public A getA() {return a}
}

当查询 D类时，应为 D.a 是延迟加载的，所以没有查询过 a表，自然就不知道该记录对应的disc为什么值，也不知道A具体是哪种子类类型。但是查询出的d对象，如果 d.a != null d.a必须有值。Hibernate会生成一个A的子类，并用它的实例作为 d.a 当你真的要访问 d.a 的方法或域时，hibernate才会真正的去查询 a 表。 这其实就是hibernate实现延迟加载的原理。但在本例中，如果你执行如下代码就会遇到 ClassCastException，

D d = session.load(D.class, 1);
C c = (C) d.getA(); //即使d.getA()确实是C类型，也会ClassCastException

hibernate生成的是A的子类，而不是B或C的子类，所以在类型转换的时候出错了。要解决这一问题，要么不要用延迟加载, 但是性能上面很可能出问题；要么不要用继承，向下面这样：

@Entity
@Table(name = "a")
public abstract class A {
 @Id
 private int oid;
 
 private String name;
 private String age;
 private String sex;
}
 
 
@Entity
@Table(name = "d")
public class D {
  @Id
  private int oid;
  @ManyToOne(fetch = FetchType.LAZY)
  private A a;
  public A getA() {return a}
}

这样实际上是限制OO的能力；要么每次都显示的重新查询改对象，向这样：

D d = session.load(D.class, 1);
C c = session.load(C.class, d.getA().getOid()) //重新查，指明类型

这样做既不方便，又不OO。

看来要想让hibernate的映射类保持对象的特性，还是有些困难的。很多时候，这些映射类最终就变成了只负责映射功能的数据库表对象了

如果在映射时，定义了 optimistic-lock=”version”，同时映射了  <version name=”version” type=”integer” unsaved-value=”negative”/>，那么就会起用hibernate的乐观锁机制。hibernate会在执行update merge等更新操作时对比数据库里的该行的version和当前对象的version是否一样，如果一样则更新，不一样则出异常。但并hibernate并不会在所有的更新操作时都做去对比这个version。

乐观锁是用来处理并发事务的。如果有多个事物同时对一行数据进行更新，那么才会检测这个version；反之，如果在一个事务内部，无论对version做怎么样的更改，都不会检测。那么hibernate是如何做到这一步的呢？在每个事务提交的时候，hibernate会判断当前事务里有哪些对象被更新到数据库里，如果这个对象处理持久化状态，则不检查它的version，如果处于游离态，则要在更新前检查version。

换句话说， 如果对象是在当前的事物里通过load方法，get方法，或者通过query等查询出来的，那么这个对象在当前事物里处于持久化状态，hibernate就不会检测version。如果对象不是在当前事务中被从数据库中读出来的，而是程序新建，或者是前一个事务或前一个session里取出来的，那么在当前事务里它就处于游离态，hibernate就会检version。

例如，有一个类Person，需要更新属性name。于你查出这个对象把这个对象在页面显示，并且让用户在页面上更改完成并提交时，form里包含那个对象的id，要更新的字段name和version。这样当用户提交后，在后台，如果你是这样做的：

//……

Transaction transaction = session.beginTransaction();

Person person = (Person) session.load( Person.class, id);

person.setName(name);

person.setVersion(version);

session.update(person);

transaction.commit();

//……

上面那种情况，因为被update的person是从当前事务中查询出来的，正处于持久化状态，所以在更新时，就算页面传来的version值比前数据库里的version值小，hibernate也不会报错，因为它根本就不会检测。如果想让hibernate检测，你可以这样做：

//……

Transaction transaction = session.beginTransaction();

Person person = new Person();

person.setId(id); 

person.setName(name);

person.setVersion(version);

session.update(person);

transaction.commit();

//……

由于是新建出来的person，这时的person处于游离态，所以在后面的更新时，hibernate就会按照你的意愿去检测version 了。

但是上面的方法还是有问题，就是如果那个Person里有很多个属性，而你只要改其中一部分，如果你不把所有的属性都扔到页面上，再在回来时写入新建的person里，那么在更新时，很可能会就会把一些你不想被更新字段给覆盖掉。而且，如果person和其它对象有外键关联，就更麻烦了。在这样的情况下，还是从数据库里取出当前对象，并更新它的那几个字段来得方便，不过这个时候如果你真的需要检测version，估计只好手动判断version 的值是否正确了。