Originally posted by Mike Weiss:
1. How does Hibernate detect changes in Object graphs (diffs) to generate appropriate SQL-Statements. E.g. if OrderItem instance is removed from Order list container ?
My understanding of the mechanisms Hibernate uses are based on building my own frameworks over the years and in porting an
EJB (session and entity beans) application to Hibernate over the past month. Caveat emptor.
When you load objects via the Session interface, Hibernate clones them and gives you a copy. It stores both the originals and copies in the Session's cache, known as a
unit of work. When you tell the Session to flush, it compares the copies to the originals to determine what SQL to issue.
This is decidely different from another, though more intrusive, option: have the objects track their own changes. This latter method is very useful when you cannot keep the session open during the course of the transaction, as in a rich client or distributed architecture.
Hibernate provides methods for working around this. In the simplest case, you can reassociate object graphs with a new Session instance with saveOrUpdateCopy(). Hibernate will reload fresh copies of the objects and put them and your versions into the Session cache for comparison during the next flush().
2. Is it possible to use only the cache implementation classes in order to create an object cache for e.g. Rich Client purposes ?
As Karl said, Hibernate provides a cache interface for others to implement (though it provides several implementations). Hibernate places this cache between the Session and the database. The Session becomes the "first-level" cache and the trans-Session one is called the "second-level" cache. If you request object A with ID X, it checks the Session, then the second-level cache, and finally the database.
[ December 20, 2004: Message edited by: David Harkness ]