Need some input/tutorial on Hibernate Internals

[Ayan Dutta]

Hi , I am learning hibernate .
I need a good tutorial on Hibernate Internals,not the basics(that can I get from any book ) .For example hibernate uses saveOrUpdate() ,but how internally it decides whether to save or update ? when we invoke merge() what happens internally ? The explanation for this sort of things I have not seen in any book so far , one way may be to have a look at the source code .
I want to have a thorough idea .
But if you guys have any link or tutorial please refer.

Regards,
Ayan

[Sathya Srinivasan]

AFAIK, there is no book that goes into that level of detail (nor do I see any specific reason why it should be that detailed). Hibernate being an open-source application, you can always crack open the source code and see how it is implemented - that would be the best and the easiest way to do it.

[Cameron Wallace McKenzie]

Originally posted by Sathya Srinivasan:
AFAIK, there is no book that goes into that level of detail.

Hmmmm...I think I might know of a really, really good Hibernate Book that tries to go into this. Check out this tutorial on How Hibernate Works:

How Hibernate Works

As far as saveOrUpdate goes, it's really as simple as whether the object being passed in has a primary key associated with it as to whether an update or a save is performed.

In Summary

So, when we create instances in our Java code, the instance is considered to be a transient instance, which means there is no mechanism in place to manage the persistent state of that instance. However, once we pass a transient instance to the save, update, or saveOrUpdate method of the Hibernate Session, we consider the transient instance to have transitioned into a persistent instance, as Hibernate will begin to manage the persistent state of that instance. Any instance associated with the Hibernate Session is said to be a persistent instance.

Saving or updating a JavaBean isn't the only way to get your hands on a persistent instance. JavaBeans that have been loaded into the Hibernate Session, either by a get or load method call, or even an HQL or criteria query, are considered to be persistent instances, and as such, any changes or updates to the state of those instances will be persisted to the database by the Hibernate Session as well.

If you do have an instance that you want to release from Hibernate's control, you can always call the evict method of the Hibernate Session, passing in the name of the instance you want freed from Hibernate's control. When an instance is no longer having its state managed by the Hibernate Session, we call that a detached instance, because while it does have a representation in the database, Hibernate isn't doing anything to keep the instance in sync with the underlying persistence store. In effect, the instance is detached from its corresponding representation in the database.

Of course, when we work with Hibernate, all of our interactions with the database must occur within the scope of a transaction. By default, when we call methods like save or update, we can never be totally sure when the corresponding record in the database is updated - all we know for sure is that once the transaction is committed, all of the changes to any of the persistent instances associated with the Hibernate Session will be saved to the database. Of course, there is always the potential that the act of saving all of the data to the database will fail for some reason, and if that does happen, Hibernate will throw a runtime exception. At this point, there's really not too much you can do, other than roll back the current transaction, and close the Hibernate Session. At this point, all of the instances that were previously under the control of the Hibernate Session become detached objects, and quite likely, are no longer in sync with the database. In such a case, you can always start a new transaction, and try to turn your detached instances back into persistent instances by re-associating them with the Hibernate Session through save or update calls, but in the end, you're probably better off just sending a friendly error message to your client application, and start any request-response cycle over again from scratch.

And that's about it; a quick description of how hibernate works, along with a simple description of what we mean when we talk about transient, persistent and detached objects.

-Cameron McKenzie