Hibernate长对话分析

在实际项目应用中，很多业务处理都需要一系列完整的与用户之间的交互，而这些用户是指对数据库有交叉访问的用户。在基于Web的应用和企业应用中，跨用户交互的数据库事务是无法接受的。例如在界面的第一页面，打开对话框，用户所看到的数据是被一个特定的 Session 和数据库事务载入的。用户可以随意修改对话框中的数据对象。过一段时间后，用户单击“保存”按钮保存修改的持久化实体，同时也期望自己是唯一修改这个信息的人，不会出现修改冲突。

从用户的角度来看，可以把这个操作单元称为长时间运行的对话（conversation），或者应用事务。 在的应用程序中，可以有很多种处理方法来实现它。

第一种处理方法是在用户思考的过程中，保持Session和数据库事务是打开的， 保持数据库锁定，以阻止并发修改，从而保证数据库事务隔离级别和原子操作。这种方式当然是一个反模式， 因为锁争用会导致应用程序无法扩展并发用户的数目。

很明显，在程序中必须使用多个数据库事务来实现这个对话。在这个例子中，维护业务处理的事务隔离变成了应用程序层的部分责任。一个对话通常跨越多个数据库事务。如果仅仅只有一个数据库事务（最后的那个事务）保存更新过的数据，而所有其他事务只是单纯的读取数据，那么应用程序事务将保证其原子性。在Hibernate中实现这种方式主要方法有：

u 自动版本化： Hibernate能够自动进行乐观并发控制 ，如果在用户思考过程中发生并发修改，Hibernate能够自动检测到。一般只在对话结束时才检查。

u 脱管对象：如果采用短对话模式，所有载入的实例在用户思考的过程中都处于与Session脱离的状态。Hibernate允许把与Session脱离的对象重新关联到Session 中，并且对修改进行持久化。自动版本化被用来隔离并发修改。

u 长会话：Hibernate的Session可以在数据库事务提交之后和底层的JDBC连接断开，当一个新的客户端请求到来的时候，它又重新连接上底层的JDBC连接。但这种情况可能会造成不必要的Session和JDBC连接的重新关联。自动版本化被用来隔离并发修改，Session通常不允许自动flush，而是在程序中明确调用flush方法。