jamesfredley commented on PR #15731: URL: https://github.com/apache/grails-core/pull/15731#issuecomment-4725472403
## Update: chained transaction manager fix + Hibernate 7 datasources app + base sync Continued making Hibernate 7.4 a drop-in for Hibernate 5.6 by cloning the flagged general functional apps to H7 and fixing the real production bugs they surfaced. Synced with the latest `8.0.x-hibernate7`. New commits: `3d82ad2c63`, `a9b8a98f52` (+ merge `8e5735500c`). ### Fixed: `ChainedTransactionManager` double-completion under Hibernate 7 (`3d82ad2c63`) A genuine H7 regression, found by cloning the `datasources` app and running it: - **Symptom:** with multiple data sources + `chainedTransactionManager.enabled: true`, every `@Rollback` transaction failed under H7 with `IllegalTransactionStateException: Transaction is already completed - do not call commit or rollback more than once`. The byte-identical app passes on H5 (30/30) and failed on H7 (30/30). - **Root cause (confirmed by instrumenting the transaction lifecycle):** `ChainedTransactionManagerPostProcessor` builds the delegate list from bean *names* (`$primaryTransactionManager` + every `*transactionManager(_.+)?` bean). Under H7 a second bean name aliases the **same** primary transaction-manager instance, so it appears twice. `MultiTransactionStatus` is keyed by instance, so the chained `commit` iterated that instance twice and committed the same `TransactionStatus` twice. - **Fix:** `ChainedTransactionManager` now dedupes delegate managers by identity (order preserved). A duplicate instance is always meaningless for this class, so it is a no-op when there is no duplicate (e.g. H5). Locked with `ChainedTransactionManagerTests.shouldDeduplicateRepeatedTransactionManagerInstances`. ### Added: Hibernate 7 `datasources` functional app (`a9b8a98f52`) `grails-test-examples/hibernate7/datasources` is a **near-identical clone** of the H5 `grails-test-examples/datasources` app - the only difference is `build.gradle` (`grails-bom` -> `grails-hibernate7-bom`, `grails-data-hibernate5` -> `grails-data-hibernate7`), so the two are trivially diffable. All four integration specs pass on H7, matching H5: - `DatasourceSwitchingSpec` 18/18, `CrossDatasourceTransactionSpec` 12/12, `MultipleDataSourcesSpec` 1/1, `OsivGspRenderingSpec` 1/1. It auto-registers as `grails-test-examples-hibernate7-datasources` and runs in the existing `hibernate7Functional` job. ### Found (documented, tracked): Hibernate 7 lazy hasMany not rendered in JSON views Cloning `views-functional-tests` to H7 showed **48/52** integration specs already pass under H7 (association/proxy/inheritance/embedded/circular rendering all work). The 4 `TeamSpec` failures share one root cause, confirmed by instrumentation: - Under H7, `Team.findById(id, [fetch:[players:'join']])` returns the `players` hasMany as an **uninitialized** `org.hibernate.collection.spi.PersistentList`. The JSON view helper by-design skips uninitialized lazy collections in non-deep mode, so `players` is dropped from the JSON (`captain`, a to-one, still renders). H5 renders the collection. - This is a GORM query-layer difference (`fetch:[assoc:'join']` not eager-initializing the collection under H7), not a view-layer bug. It is a real migration risk (JSON APIs can silently lose hasMany collections) and is tracked in the description for a focused fix. The `views`/`scaffolding` H7 clones are deferred until it is resolved (I did not ship partial/`@PendingFeature` apps). ### Also - Merged the latest `8.0.x-hibernate7` (typed attribute reads, scaffolding generics, http-client form post) - clean, no conflicts. - Updated the "Detailed issue coverage", "Known follow-up", and migration-checklist tables above to reflect the fix, the new app, and the views finding. Net since the parity pass: the multi-datasource chained-transaction regression is fixed, the `datasources` general app now has full verified H7 parity, and the remaining views/scaffolding gap is reduced to one precisely-characterized GORM query bug. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
