Inconsistent JPA behavior using no transaction, propagation SUPPORTS and OpenEntityManager pattern [SPR-13243]

[spring-projects-issues]

Andreas Benneke opened SPR-13243 and commented

We are using JPA (Hibernate 4) with Spring 4 managing the JTA transactions. To allow lazy initialization even when simply reading from the database without any transaction we added the "OpenEntityManager" pattern.

We know that there is a difference between having no transaction synchronization at all and SUPPORTS synchronization. But the JPA behaviour seems to be inconsistent somehow:

• If there is no transaction synchronization active, we get a TransactionRequiredException from Springs SharedEntityManagerCreator when trying to persist something using JPA.
• If there is only a SUPPORTS transaction synchronization active, we don't get this exception and the persist request is silently ignored. This however is exactly the situation to avoid in the SharedEntityManagerCreator when creating the above exception.
• If there is an "OpenEntityManager" pattern active, there is no exception also and the persist request is silently ignored as well.

In my opinion there is no real difference between these situations and I would expect to see this exception in all cases or none?

You can find a test case for these questions on GitHub https://github.com/abenneke/sandbox/tree/master/spring-hibernate4-transaction

---

Affects: 4.1.7

Reference URL: http://stackoverflow.com/questions/27346975

Issue Links:

• Shared EntityManager should immediately throw TransactionRequiredException if no transaction in progress [SPR-11923] #16541 Shared EntityManager should immediately throw TransactionRequiredException if no transaction in progress
• Transaction propagation SUPPORTS leads to “HHH000326: Cannot join transaction” warning [SPR-13242] #17833 Transaction propagation SUPPORTS leads to “HHH000326: Cannot join transaction” warning
• Shared EntityManager's target lookup doesn't work with Spring Data's ChainedTransactionManager [SPR-14371] #18944 Shared EntityManager's target lookup doesn't work with Spring Data's ChainedTransactionManager
• Regression: Shared EntityManager proxy insists on actualTransactiveActive flag even with SYNCHRONIZATION_NEVER [SPR-13838] #18411 Regression: Shared EntityManager proxy insists on actualTransactiveActive flag even with SYNCHRONIZATION_NEVER

Referenced from: commits 7e2a662, fca33f5

0 votes, 5 watchers

[spring-projects-issues]

Juergen Hoeller commented

Good point, we should refine that check to lead to a TransactionRequiredException even in case of a SUPPORTS transaction, probably by checking TransactionSynchronizationManager.isActualTransactionActive().

Juergen

[spring-projects-issues]

Andreas Benneke commented

Great! Thanks for fixing this so quick... :-)

[spring-projects-issues]

Frank Prumbaum commented

I am not sure about it, but it could be this fix broke spring after RC3 for our project.
We are using OpenEntityManagerInViewFilter in our MVC Controllers.

Using this code

@Controller
public final class ScriptController extends AbstractController {
	@PersistenceContext
	private EntityManager em;
	@Inject
	private ScriptletDao scriptletDao;
	@Inject
	protected PersonDao personDao;

[...]
    Person creator = personDao.getByNameUnique(getUser(request));
[...]
    Person sCreator = script.getCreator();  //detached object
    sCreator = em.merge(sCreator); //trying to get attached object leads to the error

javax.persistence.TransactionRequiredException: No EntityManager with actual transaction available for current thread - cannot reliably process 'merge' call org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:277)

We did not change our code quite some time (years) and were updating spring and hibernate libs continously
for some time. Our production code is now on Spring 4.2.RC3 and Hibernate 5.0.

Unfortnunately I didn't manage to fix the behaviour changing our initialization code

@Bean(name = "entityManagerFactory")
public EntityManagerFactory entityManagerFactory() throws PropertyVetoException {
	LocalContainerEntityManagerFactoryBean emf = new LocalContainerEntityManagerFactoryBean();
	emf.setDataSource(dataSource());
	emf.setPackagesToScan("de.axa.mad.core.md");
	emf.setJpaVendorAdapter(jpaVendorAdapter());
	emf.setJpaProperties(jpaProperties());
	emf.afterPropertiesSet();
	return emf.getObject();
}

@Bean(name = "transactionManager")
public JpaTransactionManager transactionManager() throws PropertyVetoException {
	JpaTransactionManager tm = new JpaTransactionManager();
	tm.setEntityManagerFactory(entityManagerFactory());
	tm.setTransactionSynchronization(AbstractPlatformTransactionManager.SYNCHRONIZATION_ALWAYS);
	tm.setDataSource(dataSource());
	return tm;
}

@Bean(name = "transactionTemplate")
public TransactionTemplate transactionTemplate() throws PropertyVetoException {
	TransactionTemplate template = new TransactionTemplate(transactionManager());
	return template;
}

@Bean(name = "jpaProperties")
public Properties jpaProperties() {
	Properties props = new Properties();
	props.put("hibernate.jdbc.fetch_size", "100");
	props.put("hibernate.format_sql", env.getProperty("jpa.comments.sql")); // since 4.4.0
	props.put("hibernate.search.default.indexBase", env.getProperty("hibernate.search.index"));
	props.put("hibernate.search.default.exclusive_index_use", "false");
	//props.put("hibernate.search.default.locking_strategy", "native");
	props.put("hibernate.search.default.locking_strategy", "de.axa.mad.core.utils.MadNativeFSLockFactory");
	props.put("hibernate.search.default.worker.execution", "async");  // since 4.3.20
	props.put("hibernate.search.default.refresh_interval", "500");  // since 4.3.20
	props.put("hibernate.search.lucene_version", "LUCENE_CURRENT");
	return props;
}

I didn't open any issue either, because Spring was finally released yet and the error did not happen with any prerelease version.
Now as 4.2.1 has been released and the error did not go away what should I do? Read some doku ;-) or open a new Issue?

[spring-projects-issues]

Oliver Drotbohm commented

I'd argue the exception you see is the expected behavior, as the controller doesn't create a transaction and EntityManager.merge(…) requires one by definition (see the Javadoc). I'd also argue your setup is a bit weird as you have a DAO in place but still use the EntityManager directly, which basically subverts the purpose of the DAO in the first place. Shouldn't you rather call a dao.save(…) or the like which then would trigger a transaction?

[spring-projects-issues]

Frank Prumbaum commented

You are absolutely right. This is some of our legacy code which I should replace in the first place.

Only I would like to know if this (#17834) caused the actual behaviour (before it seems
em.merge(...) triggered the OpenEntityInViewFilter to created a transaction for me).

[spring-projects-issues]

Oliver Drotbohm commented

I don't think it created a transaction but just didn't outright reject the call and relied on the actual EntityManager implementation to do that, which apparently hasn't rejected the call correctly. I guess just moving all that data access code into the DAO with proper transaction handling applied should fix this.

[spring-projects-issues]

Frank Prumbaum commented

It might be, though... I did change to code to

Person creator = personDao.getByNameUnique(getUser(request));
[...]
Person sCreator =  personDao.getById(id);

Now the second instruction fails with

org.hibernate.LazyInitializationException: could not initialize proxy - no Session

Both instructions are marked Read-Only. As we rely heavily on OpenEntityInViewFilter (we have a big, legacy JSP-Infrastructure) it
would be very hard to refactor everything to uses DTO's instead of the real entities. Mmmh.

[spring-projects-issues]

Oliver Drotbohm commented

Hard to tell without a real StackTrace and information about your DAO implementation. As we're getting sort of off-topic here, maybe a question on StackOverflow is more appropriate?

[spring-projects-issues]

Frank Prumbaum commented

Agreed. I will look into the issue a little bit more.