Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
spring-projects-issues opened this issue Jul 2, 2014 · 9 comments
Assignees
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jul 2, 2014

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:

1 votes, 6 watchers

@spring-projects-issues
Copy link
Collaborator Author

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
Copy link
Collaborator Author

Manuel Jordan commented

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

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Jul 26, 2014

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

spring-projects-issues commented Oct 10, 2014

Senén de Diego commented

Done

Senén

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants