I am writing a client application which uses hibernate to persist a bunch of objects to an HSQL database. After (re)reading the doc, boards, and faqs I still am looking for a clarification.

My app will load a bunch of objects at startup to restore the state. After that there will be multiple threads which will be accessing stuff on the net, which will lead to more objects being built and added to the memory structures, which in turn will need to be persisted.

It seems like I can't have a single Session which I use throughout because Sessions are not reentrant and different threads will be creating new objects concurrently.

On the other hand if I use a different Session in each thread and a different one in the mainline, then an object which was read into memory with SessionA might be modified (e.g. additional children) and then SaveorUpdate() with a different Session, which I think is not allowed.

What is the right way to think about this problem?

Thanks,

Pito

A Session is meant to span the lifetime of only a single use case execution. Now, what exactly constitutes a use case varies by system. But typically it is described as a single "business transaction", or unit of work

It will take us a whole chapter of the book to really define what Steve means by "business transaction" ;)

Why is it a bad idea to keep the session open for the whole life time of my *client only* application?

If you have an exception or a rollback then the session becomes invalid (although the session can be cleared in 2.1). Session are not thread safe so you will have to place locks around session access if you use it the way your describing. Sessions are very light so create and destroy as necessary.

In that case, sounds like the creation and closure of a session is just as well put in each DAO operation, i.e. per CRUD call... Or am I missing something else?
Scott

It depends on the granularity of the DAO. In many DAO based architectures there is a service layer which represents the user cases. This can be considered the level of the session. Now a use case may use multiple DAOs to perform the operation. In this situation the session can be loaded into a thread local rather than passed around the DAO hierarchy. As Gavin has indicated sessions usage can be applied widely depending on the context and he has indicated this will be a focus topic in the book.

It must be simple to understand: Session and DB transaction lifespan is the same. I think all Session methods must throw exception after transaction, it is possible to reuse the same session for next transaction, but it is not a major optimization and error prone.

It is very trivial to understand in web application: Session/Transaction per Request/Thread ( object returned from pool is a "new" object in this analogy)

FYI, that's exactly how Hibernate Session management is implemented in the Spring Framework: A Spring-managed, Hibernate-aware transaction demarcates both a database transaction and the lifespan of the associated Hibernate Session.

Spring also clearly separates transaction demarcation and transaction participation: This addresses units-of-work that span multiple DAO method invocations. Under the hood, a ThreadLocal Session is used, but application code does not have to bother.

Effectively, Spring offers all the benefits of EJB CMT or BMT, i.e. declarative or programmatic transaction demarcation, for lightweight POJOs. In addition, it offers pluggable transaction strategies: JTA is just one option; demarcating code does not depend on any particular strategy.

Spring's Hibernate transaction strategy is perfect for accessing a single database with Hibernate. This enables declarative, high-level transaction management for Hibernate without any JTA or EJB dependency - for example, in plain Tomcat or a standalone application!

Juergen

This is the general approach and should the the primary way of using the system. Having said that, there are cases where you may need to not be restricted to this design. Hibernate does not tie the Session and Transaction life cycle tightly together. I agree that more care is required when the lifespans are not the same.