tailieunhanh - manning Hibernate in Action phần 5

Tham khảo tài liệu 'manning hibernate in action phần 5', công nghệ thông tin, kỹ thuật lập trình phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả | The persistence lifecycle 119 is one of Hibernate s main selling points. We discuss this usage in the next chapter as an implementation technique for long-running application transactions. We also show you how to avoid the DTO anti- pattern by using detached objects in chapter 8 in the section Rethinking data transfer objects. Hibernate also provides an explicit detachment operation the evict method of the Session. However this method is typically used only for cache management a performance consideration . It s not normal to perform detachment explicitly. Rather all objects retrieved in a transaction become detached when the Session is closed or when they re serialized if they re passed remotely for example . So Hibernate doesn t need to provide functionality for controlling detachment of subgraphs. Instead the application can control the depth of the fetched subgraph the instances that are currently loaded in memory using the query language or explicit graph navigation. Then when the Session is closed this entire subgraph all objects associated with a persistence manager becomes detached. Let s look at the different states again but this time consider the scope of object identity. The scope of object identity As application developers we identify an object using Java object identity a b . So if an object changes state is its Java identity guaranteed to be the same in the new state In a layered application that might not be the case. In order to explore this topic it s important to understand the relationship between Java identity a b and database identity .equals . Sometimes both are equivalent sometimes they aren t. We refer to the conditions under which Java identity is equivalent to database identity as the scope of object identity. For this scope there are three common choices A primitive persistence layer with no identity scope makes no guarantees that if a row is accessed twice the same Java object instance will be returned to the .