Bound to thread, scoped to the transaction - Hibernate

Question

While trying to strengthen my Transactional skills, I came across Hibernate's Transaction demarcation with plain JDBC. One of the points explained is that the Session is bound to the current thread (because it can't be bound to the Transaction) but it is scoped to the transaction.

In fact, I come across hibernate session's association with the current thread in many articles and it always bothers me.

What I want to know is what does it mean for the current session to be 'bound' to the current thread? For example when you say the session is 'scoped' with the transaction I understand that the (current)session will be flushed, closed when the transaction is over. So what does "binding" mean here? What does it mean in terms of multithreading? I don't want to make the question boring but I want to understand this association between the session and the thread clearly. Will be glad to read an article on this or have some working examples.

Thanks in advance.

Answer 1

If we take for example some transactional Spring code:

@Transactional // a new session was created here 
public void someTransactionalMethod() {
    ...
}

This means that the spring container needs to create a session, if none was already present. with this two questions come to mind:

• where to store the session just created
• where to go and see if an session was already created, and if so retrieve it?

The session that is used by the Spring aspect to ensure @Transactional functionality needs to be stored somewhere other than the application code.

This could be stored anywhere: in a singleton, in the session, or in a ThreadLocal variable, effectively bounding it to the thread executing the application code.

Every thread as a map where we can store variables, and ThreadLocal is a convenient abstraction around it, allowing to create thread-scoped variables.

There is no technical constraint to bind the session to a thread, it's just a design decision that is frequent: give the variable the narrowest scope possible, avoid global variables, etc.

In the case of applications running in servlet containers, there is guarantee that for a given HTTP request, the same thread will be used to treat the whole request up until the generation of the response.

In other environments the same guarantee is made, so the designers of the most frequently used transaction managers, JpaTransactionManager and HibernateTransactionManager decided to use the Thread as the place where the entity manager / hibernate session is stored.

Binding the session/entity manager to a thread using a ThreadLocal variable is a simple way to ensure that no multi-threaded bugs would ever occur in the transaction management code, it's a concurrent programming strategy known as Thread Confinement.