4.1.4 对象身份的范围

 

作为开发人员，我们使用==来识别一个对象的身份。因此，如果一个对象更改了状态以后，它的身份是否仍然和原来一样？在分层的程序当中，可能并不如此简单。

为了更深入探讨这个问题，需要明白在java对象身份和数据库标识之间的关系。有些时候，它们是等价的，而有时它们又不是相等的。我们把这个问题归结为对象身份的范围。

对于这个范围，有三种一般的选择：

（1）如果一个持久层没有身份标识的范围的话，那么就无法保证同一行数据被访问两次，不同的访问会返回同一个Java对象。这将带来问题：如果程序修改了代表同一行数据的两个不同对象，会造成状态的不一致。

（2）使用了transaction-scoped的身份标识的持久层能够保证在单一的事务中，只有一个对象实体能够代表一个特定的数据行。这就避免了刚才提到的问题，同时能够在事务级提供一定的缓存能力。

（3）Process-scoped则更进一步，在每个JVM中保证只有一个对象实体代表同一行数据。

对于典型的web或者商务程序，transaction-scoped是一个很好的选择。而Process-scoped提供了一些其他的好处包括缓存的使用以及在多个事务中对象实体的重用。但是，在多线程的环境中，程序同步会带来性能上的消耗。因此，在多线程环境中，每个线程只和那些属于其自身的持久化实体打交道。

Hibernate使用的是transaction-scoped。实际上，Hibernate的身份标识范围是Session实例，因此如果使用一个Session的话，那么能够保证对象的同一性。但是，Session并不代表是同一个事务。我们将在接下来的部分讨论这个概念。让我们重新把注意力回到持久化生命周期以及身份标识范围上。

如果你在同一个Session中请求了两次使用同一数据库标识的对象，那么返回的结果将是两个指向内存同一个对象的不同引用。下面的代码示例将展示这种行为，通过在不同的Session中使用load()方法。

当在同一个Session中的时候，对象a和b不仅仅拥有同一个数据库标识，它们也拥有同一个Java对象标识。一旦超越这个边界，Hibernate则无法保证Java对象标识的相同性。因此，a和b2并不相等。但是关于数据库标识的验证，a.getId().equals(b2.getId())仍然会返回true。

要进一步讨论身份标识范围的问题，我们需要考虑当对象超出其身份标识范围的时候，持久层如何处理指向对象的引用。例如，对于Hibernate来说，是否允许一个引用指向detached对象。