Closed
Description
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:
Metadata
Metadata
Assignees
Type
Projects
Relationships
Development
No branches or pull requests
Participants
Activity
jhoeller commentedon Feb 4, 2022
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): #22128That 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.
[-]Read-only transactions not supported on Hibernate 6[/-][+]HibernateJpaDialect compatibility with Hibernate 6 (read-only transactions etc)[/+]odrotbohm commentedon Feb 4, 2022
Once I avoided read-only transactions by rather using a simple
@Transactionalthe 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.
jhoeller commentedon Feb 4, 2022
Good point, there's no classic JPA binding for it anymore, it's exclusively built on
jakarta.persistenceindeed. And it won't be usable withorm.hibernate5either 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 :-)jhoeller commentedon Feb 4, 2022
Alright, so we'll definitely sort out
HibernateJpaDialectcompatibility 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.odrotbohm commentedon Feb 4, 2022
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.
jhoeller commentedon Feb 4, 2022
It turns out that it is indeed straightforward to support both Hibernate 5.6 and 6.0 through a revision of
HibernateJpaDialectwhere it retrieves the current JDBC connection differently. The correct replacement isgetJdbcCoordinator().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
HibernateJpaVendorAdapterand 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.hibernate6package next toorm.hibernate5, or possibly as a replacement fororm.hibernate5. This mostly depends on what we are going to recommend for existingorm.hibernate5users: staying on Hibernate 5.6, upgrading to Hibernate 6.0 viaorm.hibernate6, or upgrading to Hibernate 6.0 via JPA.odrotbohm commentedon Feb 8, 2022
Thanks for that, Jürgen. Verified working as expected now! 🙇
HibernateTransactionManagercompatibility with Hibernate 6.0/6.1 #28813