Spring @Transactional(Propagation.NEVER) should create Hibernate session?

Question

Let's assume that we have correctly configured JPA backed by Hibernate (version 4.3.11) in Spring (version 4.2.7). Hibernate first level cache is enabled. We use declarative transactions.

We have OuterBean:

@Service public class OuterBean {      @Resource     private UserDao userDao;      @Resource     private InnerBean innerBean;      @Transactional(propagation = Propagation.NEVER)     public void withoutTransaction() {         User user = userDao.load(1l);         System.out.println(user.getName());  //return userName         innerBean.withTransaction();         user = userDao.load(1l);         System.out.println(user.getName());  //return userName instead of newUserName     }  } 

And InnerBean that is called from OuterBean:

@Service public class InnerBean {      @Resource     private UserDao userDao;      @Transactional     public void withTransaction() {         User user = userDao.load(1l);         user.setName("newUserName");     }  } 

Is it correct behaviour that method user.getName() in OuterBean returns the same value twice (second time is after update name in database)?

In other words is it correct behaviour that @Transactional(propagation = Propagation.NEVER) creates Hibernate session for method withoutTransaction() that causes that second call user.getName() reads from Hibernate first level cache instead of database?

---

EDIT

To explain problem more I attache trace from creation of hibernate sessions

TRACE org.hibernate.internal.SessionFactoryImpl$SessionBuilderImpl  - Opening Hibernate Session.  tenant=null, owner=org.hibernate.jpa.internal.EntityManagerImpl@c17285e TRACE org.hibernate.internal.SessionImpl  - Opened session at timestamp: 14689173439 TRACE org.hibernate.internal.SessionImpl  - Setting flush mode to: AUTO TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL userName TRACE org.hibernate.internal.SessionFactoryImpl$SessionBuilderImpl  - Opening Hibernate Session.  tenant=null, owner=org.hibernate.jpa.internal.EntityManagerImpl@715c48ca TRACE org.hibernate.internal.SessionImpl  - Opened session at timestamp: 14689173439 TRACE org.hibernate.internal.SessionImpl  - Setting flush mode to: AUTO TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL TRACE org.hibernate.internal.SessionImpl  - Automatically flushing session TRACE org.hibernate.internal.SessionImpl  - before transaction completion TRACE org.hibernate.internal.SessionImpl  - after transaction completion TRACE org.hibernate.internal.SessionImpl  - Closing session TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL userName TRACE org.hibernate.internal.SessionImpl  - Closing session 

Now let's compare trace when I remove @Transactional(propagation = Propagation.NEVER)

TRACE org.hibernate.internal.SessionFactoryImpl$SessionBuilderImpl  - Opening Hibernate Session.  tenant=null, owner=org.hibernate.jpa.internal.EntityManagerImpl@4ebd2c5f TRACE org.hibernate.internal.SessionImpl  - Opened session at timestamp: 14689203905 TRACE org.hibernate.internal.SessionImpl  - Setting flush mode to: AUTO TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL TRACE org.hibernate.internal.SessionImpl  - Closing session userName TRACE org.hibernate.internal.SessionFactoryImpl$SessionBuilderImpl  - Opening Hibernate Session.  tenant=null, owner=org.hibernate.jpa.internal.EntityManagerImpl@5af84083 TRACE org.hibernate.internal.SessionImpl  - Opened session at timestamp: 14689203905 TRACE org.hibernate.internal.SessionImpl  - Setting flush mode to: AUTO TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL TRACE org.hibernate.internal.SessionImpl  - Automatically flushing session TRACE org.hibernate.internal.SessionImpl  - before transaction completion TRACE org.hibernate.internal.SessionImpl  - after transaction completion TRACE org.hibernate.internal.SessionImpl  - Closing session TRACE org.hibernate.internal.SessionFactoryImpl$SessionBuilderImpl  - Opening Hibernate Session.  tenant=null, owner=org.hibernate.jpa.internal.EntityManagerImpl@35f4f41f TRACE org.hibernate.internal.SessionImpl  - Opened session at timestamp: 14689203906 TRACE org.hibernate.internal.SessionImpl  - Setting flush mode to: AUTO TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL TRACE org.hibernate.internal.SessionImpl  - Setting cache mode to: NORMAL TRACE org.hibernate.internal.SessionImpl  - Closing session newUserName 

Please notice when I omit @Transactional(propagation = Propagation.NEVER) separate session is create for every invocation of method from userDao.

So my question can be formulated also as

Shouldn’t be @Transactional(propagation = Propagation.NEVER) implemented in Spring as a guardian that prevents us from accidental use of transaction, without any side effect (session creation)?

Answer 1

The behavior is correct - Hibernate will always create a session (how else would you expect it to perform any operation?), and by loading the entity you have associated it with that session. Since withoutTransaction is not participating in a transaction, the changes made within withTransaction will happen within a new transaction and shouldn't be visible unless you call refresh, which will force a re-load from the database.

I'm quoting Hibernate's official documentation:

The main function of the Session is to offer create, read and delete operations for instances of mapped entity classes. Instances may exist in one of three states:

• transient: never persistent, not associated with any Session
• persistent: associated with a unique Session detached: previously
• persistent, not associated with any Session

Transient instances may be made persistent by calling save(), persist() or saveOrUpdate(). Persistent instances may be made transient by calling delete(). Any instance returned by a get() or load() method is persistent.

Taken from Java Persistence With Hibernate, Second Edition by Christian Bauer, Gavin King, and Gary Gregory:

The persistence context acts as a first-level cache; it remembers all entity instances you’ve handled in a particular unit of work. For example, if you ask Hibernate to load an entity instance using a primary key value (a lookup by identifier), Hibernate can first check the current unit of work in the persistence context. If Hibernate finds the entity instance in the persistence context, no database hit occurs—this is a repeatable read for an application. Consecutive em.find(Item.class, ITEM_ID) calls with the same persistence context will yield the same result.

Also from Java Persistence With Hibernate, Second Edition:

The persistence context cache is always on—it can’t be turned off. It ensures the following:

• The persistence layer isn’t vulnerable to stack overflows in the case of circular references in an object graph.
• There can never be conflicting representations of the same database row at the end of a unit of work. The provider can safely write all changes made to an entity instance to the database.
• Likewise, changes made in a particular persistence context are always immediately visible to all other code executed inside that unit of work and its persistence context. JPA guarantees repeatable entity-instance reads.

Concerning transactions, here's an excerpt taken from official Hibernate's documentation:

Defines the contract for abstracting applications from the configured underlying means of transaction management. Allows the application to define units of work, while maintaining abstraction from the underlying transaction implementation (eg. JTA, JDBC).

So, to sum it up, withTransaction and withoutTransaction will not share UnitOfWork and therefore will not share the first-level cache, which is why the second load returns the original value.

As to the reasons why these two methods do not share the unit of work, you can refer to Shailendra's answer.

EDIT:

You seem to misunderstand something. A session must always be created - that's how Hibernate works, period. Your expectation of no sessions being created is equal to expecting to execute a JDBC query without having a JDBC connection :)

The difference between your two examples is that with @Transactional(propagation = Propagation.NEVER) your method is intercepted and proxied by Spring and only a single session is created for the queries in withoutTransaction. When you remove the annotation you exclude your method from Spring's transactional interceptor so a new session will be created for each DB-related operation. I repeat again, and I cannot stress this enough - you must have an open session to perform any queries.

As far as guarding goes - try swapping the annotations on the two methods by making withTransaction use Propagation.NEVER and withoutTransaction use the default @Transactional annotation and see what happens (spoiler: you'll get an IllegalTransactionStateException).

EDIT2:

As for why the session is shared between two loads in the outer bean - that's just what JpaTransactionManager is supposed to do, and by annotating your method with @Transactional you've notified Spring that it should use the configured transaction manager to wrap your method. Here's what the official documentation says about JpaTransactionManager's expected behavior:

PlatformTransactionManager implementation for a single JPA EntityManagerFactory. Binds a JPA EntityManager from the specified factory to the thread, potentially allowing for one thread-bound EntityManager per factory. SharedEntityManagerCreator and @PersistenceContext are aware of thread-bound entity managers and participate in such transactions automatically. Using either is required for JPA access code supporting this transaction management mechanism.

Also, to know how Spring is handling declarative transaction management (i.e. @Transactional annotations on methods), refer to the official documentation. For ease of navigation, I'll include a quote:

The most important concepts to grasp with regard to the Spring Framework’s declarative transaction support are that this support is enabled via AOP proxies, and that the transactional advice is driven by metadata (currently XML- or annotation-based). The combination of AOP with transactional metadata yields an AOP proxy that uses a TransactionInterceptor in conjunction with an appropriate PlatformTransactionManager implementation to drive transactions around method invocations.

Answer 2

First of all, as you use hibernate behind JPA API I will use the term EntityManager instead of session (strictly the same thing, just a matter of terminology).

Every access to the database using JPA will involve an EntityManager, you are fetching entities, you need an EntityManager (EM). What's called 1st level cache is nothing more than the EM managed entities state.

Theoretically the lifecycle of the EM is short and bound to a unit of work (and so generally to a transaction, see Struggling to understand EntityManager proper use).

Now JPA can be used in different way : Container-Managed or User-Managed persistence. When the EM is managed by the container (your case, here spring is the container) this last is in charge of managing the EM scope / lifecycle (create, flush and destroy it for you). As the EM is bounded to a transaction / Unit of Work, this task is delegated to the TransactionManager (the object handling the @Transactional annotations).

When you annotate a method using @Transactional(propagation = Propagation.NEVER), you are creating a spring logical transaction scope which will ensure that there is no existing underlying JDBC transaction bound to an eventual existing EM, which will not create one and will use JDBC autocommit mode but which will create an EM for this logical transaction scope if none already exists.

Regarding the fact that a new EM instance is created for each DAO call when no transaction logical scope is defined, you have to remember that you cannot access database using JPA outside of the EM. AFAIK hibernate used to throw a no session bound to thread error in this case but this may have evolved with later releases, otherwise your DAO may be annotated with @Transactional(propagation = Propagation.SUPPORT) which would also automatically create an EM if no enclosing logical scope exists. This is a bad practice as transaction should be defined at the unit of work, eg. the service level and not the DAO one.