Isolation support for JPA with Hibernate EntityManager 4 [SPR-11942]

[spring-projects-issues]

Manuel Jordan opened SPR-11942 and commented

I am doing a research about Spring Framework and explicitly with @Transactional, it working together with JdbcTemplate, Hibernate, JPA, and finally with Spring Data - JPA. A project for each one of course.

I have a huge problem, the projects based with JPA and Spring Data JPA, do not work in a 100% with @Transanctional through Isolations: the following error message appears:

"Standard JPA does not support custom isolation levels - use a special JpaDialect for your JPA implementation"

I know it is a problem by itself of JPA. I did a research in Google and practically all have the same solution, create a customized class to around this problem.

I think Spring Framework should has available an own implementation functional and tested for the community. Isolations are very important.

If I am hired to do a migration from any Spring Project where it works with Jdbc/Hibernate, I am not able to migrate to Spring Data JPA. Because I am totally sure the services for complex use cases are working with Isolations, for example Serializable, for example for Kardex/Warehouse stock control and same consideration about cash, it closely related in the scenario for many users/threads (cashier) in a Mall.

Would be possible see Isolation support for Spring Framework: 4.1.x or 4.6.x?.

Thank You

---

Affects: 4.0.5

Issue Links:

• How to implement Pessimistic Locking with JPA [SPR-3812] #8492 How to implement Pessimistic Locking with JPA
• HibernateJpaDialect does not support setting a specific isolation level per transaction [SPR-5012] #9687 HibernateJpaDialect does not support setting a specific isolation level per transaction
• readOnly transaction doesn't work with JPA and Hibernate 4 [SPR-8959] #13599 readOnly transaction doesn't work with JPA and Hibernate 4
• Misleading exception message for using JPA with custom IsolationLevels [SPR-8325] #12974 Misleading exception message for using JPA with custom IsolationLevels
• HibernateJpaDialect should warn about connection release mode other than ON_CLOSE (when upgrading from 4.0.x) [SPR-13269] #17860 HibernateJpaDialect should warn about connection release mode other than ON_CLOSE (when upgrading from 4.0.x)
• EclipseLinkJpaDialect does not support declarative transaction isolation [SPR-12319] #16924 EclipseLinkJpaDialect does not support declarative transaction isolation
• OpenJpaDialect does not support declarative transaction isolation [SPR-12333] #16938 OpenJpaDialect does not support declarative transaction isolation

1 votes, 6 watchers

[spring-projects-issues]

Juergen Hoeller commented

The main reason why we're still not providing this is the lack of a proper resource cleanup callback in JPA...

Storing the Connection and cleaning it up after JPA commit isn't reliable, unfortunately, since the Connection will already have been returned to the connection pool by JPA before... So one would actually clean up a connection that you don't own anymore; it might even have been handed out to another caller on another thread in the meantime.

Another variant suggested was to let the connection pool restore the isolation level to a default every time a connection is being returned to the pool. That would be reliable but unfortunately Spring doesn't control the connection pool that you're using; so that solution would only work in a custom arrangement like that. We can't prevent misuse of it.

All of that said, we can revisit the problem against the latest JPA provider implementations and see whether there's anything new we can do there.

Juergen

[spring-projects-issues]

Manuel Jordan commented

Thanks by the explanation. Perhaps who is behind of HibernateJpaVendorAdapter should does this improvement.

[spring-projects-issues]

Juergen Hoeller commented

As per my comment on #13599, we could use an opt-in mode where - based on a specific deployment flag, or based on well-known connection pools - we do allow for the use of setReadOnly and setIsolationLevel. Given how popular this request is, I'm considering to revisit this for 4.1 still.

Juergen

[spring-projects-issues]

Manuel Jordan commented

Hi Juergen, thanks by your support and by let me know the status of this situation. Yes popular and crucial, how you can see mostly due by Spring Data JPA. I have a friendly suggestion, when the time be appropriate, would you write a blog post about this new feature?. I am sure the audience would be happy reading and understanding the problem and how Spring resolves that problem with the new feature. I thought it has been solved through JEE 7 by itself, but seems they trust through "Lock Mode". Thank You.

[spring-projects-issues]

Juergen Hoeller commented

As of 4.1 RC2, HibernateJpaDialect does prepare the JDBC Connection by default if on Hibernate 4 (where the connection release mode is ON_CLOSE instead of Hibernate EntityManager 3.6's AFTER_TRANSACTION), with Hibernate 4.2+ strongly recommended (since only there the actual physical Connection is being returned to us).

Analogous to HibernateTransactionManager, there is a "prepareConnection" flag on HibernateJpaDialect which allows for overriding the actual mode of operation. This is easily accessible from HibernateJpaVendorAdapter now which declares HibernateJpaDialect from its getJpaDialect() method.

Juergen

[spring-projects-issues]

Manuel Jordan commented

Thank You Juergen, it is going to be fantastic for the community!

How a friendly suggestion, a post about this in the Spring.io's blog would be very interesting.

[spring-projects-issues]

Senén de Diego commented

Hello,
EclipseLinkJpaDialect has the same limitation regarding transactions isolation. Any chance it will be also fixed?. Does an approach like the one proposed here make sense?
Thank you

[spring-projects-issues]

Juergen Hoeller commented

Please create a separate JIRA issue for isolation level support with EclipseLink... We'll see what we can do in time for 4.1.2 still.

Juergen

[spring-projects-issues]

Senén de Diego commented

Done

Senén