fix: share one connection between Hibernate and JDBC DHIS2-22067 - #25041
Merged
Conversation
teleivo
marked this pull request as ready for review
September 8, 2026 11:46
JpaTransactionManager was created without a DataSource, so Spring never registered a ConnectionHolder under the DataSource key. Every @transactional method mixing Hibernate and a plain JdbcTemplate took a second connection from the same pool which was not enlisted in the transaction: its statements commit immediately and a rollback does not cover them. This is why the org unit merge can destroy data. Its JDBC deletes of datavalue and dataapproval commit as they run, so a later failure rolls back the Hibernate work while the deleted rows stay gone. Introduced in 2.41 by 6eb421d (#14626, TECH-1517), which swapped HibernateTransactionManager for JpaTransactionManager and dropped its setDataSource call.
|
enricocolasante
approved these changes
Sep 8, 2026
david-mackessy
approved these changes
Sep 8, 2026
teleivo
added a commit
that referenced
this pull request
Sep 9, 2026
) (#25072) JpaTransactionManager was created without a DataSource, so Spring never registered a ConnectionHolder under the DataSource key. Every @transactional method mixing Hibernate and a plain JdbcTemplate took a second connection from the same pool which was not enlisted in the transaction: its statements commit immediately and a rollback does not cover them. This is why the org unit merge can destroy data. Its JDBC deletes of datavalue and dataapproval commit as they run, so a later failure rolls back the Hibernate work while the deleted rows stay gone. Introduced in 2.41 by 6eb421d (#14626, TECH-1517), which swapped HibernateTransactionManager for JpaTransactionManager and dropped its setDataSource call.
teleivo
added a commit
that referenced
this pull request
Sep 9, 2026
) (#25071) JpaTransactionManager was created without a DataSource, so Spring never registered a ConnectionHolder under the DataSource key. Every @transactional method mixing Hibernate and a plain JdbcTemplate took a second connection from the same pool which was not enlisted in the transaction: its statements commit immediately and a rollback does not cover them. This is why the org unit merge can destroy data. Its JDBC deletes of datavalue and dataapproval commit as they run, so a later failure rolls back the Hibernate work while the deleted rows stay gone. Introduced in 2.41 by 6eb421d (#14626, TECH-1517), which swapped HibernateTransactionManager for JpaTransactionManager and dropped its setDataSource call.
teleivo
added a commit
that referenced
this pull request
Sep 9, 2026
) (#25070) JpaTransactionManager was created without a DataSource, so Spring never registered a ConnectionHolder under the DataSource key. Every @transactional method mixing Hibernate and a plain JdbcTemplate took a second connection from the same pool which was not enlisted in the transaction: its statements commit immediately and a rollback does not cover them. This is why the org unit merge can destroy data. Its JDBC deletes of datavalue and dataapproval commit as they run, so a later failure rolls back the Hibernate work while the deleted rows stay gone. Introduced in 2.41 by 6eb421d (#14626, TECH-1517), which swapped HibernateTransactionManager for JpaTransactionManager and dropped its setDataSource call.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
JpaTransactionManagerwas created without aDataSource, so Spring never registered aConnectionHolderunder theDataSourcekey. Every@Transactionalmethod mixing Hibernate with a plainJdbcTemplatetook a second connection from the same pool which was not enlisted in the transaction: its statements commit immediately and a rollback does not cover them.Fixed by passing the same injected
actualDataSourcebean theJdbcTemplates get.Why it matters: the org unit merge can destroy data.
merge()is one transaction over 20 handlers, interleaving Hibernate ones with two raw-JDBC ones that deletedatavalueanddataapproval. Those deletes commit as they run, so a later failure (a tracker handler, deleting the sources, an optimistic lock at commit) rolls back the Hibernate work and leaves the source org units present with their data gone. About a dozen handlers run inside that window.Introduced in 2.41 by 6eb421d ("feat: support JPA annotation mapping for object model", #14626, TECH-1517), which swapped
HibernateTransactionManagerforJpaTransactionManagerand dropped itssetDataSourcecall. Affects 2.41, 2.42, 2.43 and master.Analysis: https://dhis2.atlassian.net/browse/DHIS2-22067