Hibernate long running conversations with persist() and save()

Question

The Hibernate document says that persist() is useful compared to save() for long-running conversations with Session/Persistence context

persist()

This is useful in long-running conversations with an extended Session/persistence context.

save()

This is problematic in a long-running conversation with an extended Session/persistence context.

1) What it means when it says Persistence context ?

2) Can you please provide an example on what are long-running conversations ? Is this applicable for web applications?

Thanks!

Update: This post gave me clear understanding for my first query - Persistence context as:

At runtime whenever a session is opened and closed, between those open and close boundaries Hibernate maintains the object in a Persistence Context. Think of it like a first level runtime cache which hibernate controls. Hibernate does automatic dirty checking and transactional write-behind for the entity managed in Persistent Context. Hibernate guarantee a scope of Java object identity in this cache. Only one object instance representing a particular database row exists in the cache.

Answer 1

A conversation is the interaction of the end user with the UI in order to perform a business task. This interaction will typically span many UI actions .

Hibernate manages entities in a persistence context that is associated with a Hibernate session . There are two patterns used to integrate a Hibernate back-end with a UI front-end:

session per conversation : A hibernate session is created when a user begins the conversation and is kept alive until the user aborts or finishes the conversation. When the latter happens, a transaction begins, the session is flushed and closed, thus sending SQL to the database(s) and the transaction is committed/rolled back.

session per request (UI action) : A hibernate session is created when a user performs a UI action. For each UI action a transaction begins, the code involving this action is run, the session may be flushed and closed and the transaction is committed/rolled back. The developer is responsible for re-attaching detached entities , previously managed in on the new session, if applicable.

The first pattern might look more appealing, but, in practice, especially when web applications are concerned the second is favored, because unless the UI is extremely simple, it is much easier to implement. You might want to look at how to implement the open session in view pattern (another name for the session per request pattern) with a servlet filter or lookup the documentation of the web application framework of your choice on how it supports this.

Another thing to note is how to perform conversation isolation (similar concept with transaction isolation on databases). This deals with the possibility that two users working simultaneously with the same data might override each others changes. Have a look at optimistic locking with timestamps or versions.