During our work to investigate the compatibility with Hibernate 6 in Spring Data JPA we ran into an issue surfacing in Spring Frameworks transaction management:
In ….beginTransaction(…), HibernateJpaDialect calls SessionImplementor.connection() a method that has been removed in CR1 (could've been in one of the betas already, I didn't check) to issue read-only transactions. It looks like the new way to access the Connection is calling ….getJdbcConnectionAccess().obtainConnection().
Related tickets: * spring-projects/spring-data-jpa#2423
Comment From: jhoeller
We aim for a complete Hibernate 6.0 support story in our own 6.0 M3, not sure yet how far we'll go (native API via orm.hibernate6? or just with JPA? keeping up Hibernate 5.x support in parallel? etc): #22128
That said, it's definitely worth considering what we could do in 5.3.x to allow for using Hibernate 6.0 with our JPA support at least. We might want to leniently tolerate it at runtime for a start, even without full alignment yet. Let's use this ticket for it.
Comment From: odrotbohm
Once I avoided read-only transactions by rather using a simple @Transactional the integration tests using Hibernate 6 CR1 on a Boot 3 M1 ran just fine. I.e. it might be just that particular issue for starters. That's why I thought I'd open the ticket around something actionable. But of course, as you see fit.
Oh, H6 is JakartaEE based. I guess that is a showstopper for any support of it in our 5.x generation.
Comment From: jhoeller
Good point, there's no classic JPA binding for it anymore, it's exclusively built on jakarta.persistence indeed. And it won't be usable with orm.hibernate5 either due to plenty of incompatibilities in the native Hibernate API. Alright, so Hibernate ORM 6.0 becomes a Spring Framework 6.0 only topic then :-)
Comment From: jhoeller
Alright, so we'll definitely sort out HibernateJpaDialect compatibility for 6.0 M3 for a start, using this ticket. Full Hibernate 6.0 alignment - or even Hibernate 6.0 baselining - might take longer anyway, let's use #22128 for that part then.
Comment From: odrotbohm
I just realized that the API I found and suggested as workaround (never tested using it myself, though) also already exists in 5.6.5. I.e. we could try to just move that in 6.0 but stick to the Hibernate 5.x baseline.
Comment From: jhoeller
It turns out that it is indeed straightforward to support both Hibernate 5.6 and 6.0 through a revision of HibernateJpaDialect where it retrieves the current JDBC connection differently. The correct replacement is getJdbcCoordinator().getLogicalConnection().getPhysicalConnection() for obtaining the current connection held by the session, as far as the connection release mode is appropriate for it. This seems to work fine on 5.6 as well as 6.0.
The other area affected is HibernateJpaVendorAdapter and its selection of default dialects for the database enum. Those dialects seem to be deprecated now, the Informix dialect is even gone completely. However, this shouldn't be a big deal since we recommend explicit Hibernate dialect configuration in any case (rather than relying on our database enum).
From that perspective, we seem to be covered in terms of JPA compatibility, so I'll close this ticket right away. The main remaining part for #22128 is whether we want/need an orm.hibernate6 package next to orm.hibernate5, or possibly as a replacement for orm.hibernate5. This mostly depends on what we are going to recommend for existing orm.hibernate5 users: staying on Hibernate 5.6, upgrading to Hibernate 6.0 via orm.hibernate6, or upgrading to Hibernate 6.0 via JPA.
Comment From: odrotbohm
Thanks for that, Jürgen. Verified working as expected now! 🙇