hibernate/hibernate-orm · error · HibernateException
Problem locating/validating JTA transaction
Error message
Problem locating/validating JTA transaction
What it means
Catch-all wrapper thrown when TransactionManager.getTransaction() or Transaction.getStatus() raised an unexpected system exception rather than returning normally. The real failure (JNDI problem, transaction manager not started, recovery store error) is attached as the cause; the HibernateException message itself is generic on purpose.
Source
Thrown at hibernate-core/src/main/java/org/hibernate/context/internal/JTASessionContext.java:116
private static @Nonnull Transaction getTransaction(TransactionManager transactionManager) {
try {
final var transaction = transactionManager.getTransaction();
if ( transaction == null ) {
throw new HibernateException( "Unable to locate current JTA transaction" );
}
if ( !isActive( transaction.getStatus() ) ) {
// We could register the session against the transaction even though it is
// not started, but we'd have no guarantee of ever getting the map
// entries cleaned up (aside from spawning threads).
throw new HibernateException( "Current transaction is not in progress" );
}
return transaction;
}
catch ( HibernateException e ) {
throw e;
}
catch ( Throwable t ) {
throw new HibernateException( "Problem locating/validating JTA transaction", t );
}
}
/**
* Builds a {@link CleanupSync} capable of cleaning up the current session map as an after transaction
* callback.
*
* @param transactionIdentifier The transaction identifier under which the current session is registered.
* @return The cleanup synch.
*/
private CleanupSync buildCleanupSynch(Object transactionIdentifier) {
return new CleanupSync( transactionIdentifier, this );
}
/**
* Strictly provided for subclassing purposes; specifically to allow long-session
* support. This implementation always just opens a new session.
*View on GitHub (pinned to fad1729dce)
Solutions
- Read the cause chain — it carries the actual TM/JNDI/store error and names the resource to fix
- Verify the transaction manager starts standalone (Narayana/Atomikos bootstrap smoke test) before wiring Hibernate
- Clear stale transaction recovery locks/object store leftovers only after confirming no live TM owns them
- Align JTA provider and hibernate.transaction.jta.platform versions, and prefer autodetection inside EE containers
Defensive patterns
Strategy: try-catch
Try / catch
try {
return sessionFactory.getCurrentSession();
} catch (org.hibernate.HibernateException e) {
Throwable root = e;
while (root.getCause() != null) root = root.getCause();
log.error("JTA infrastructure failure accessing current session: {}", root, root); // root names the real TM/JNDI/store error
throw e;
} Prevention
- Always inspect the cause chain before acting on this wrapper
- Smoke-test transaction-manager startup independently of Hibernate
- Keep JTA provider, its object store, and hibernate.transaction.jta.platform versions aligned
When it happens
Trigger: Broken transaction-manager wiring: configured JtaPlatform class present but its TM/JNDI backend unavailable, Narayana/Atomikos not started or its object store locked, or a TM that throws on getTransaction()/getStatus() in an unexpected state.
Common situations: Clustered TM misconfiguration; concurrent boot leaving the recovery store locked (stale .tx locks); partial JTA dependencies after a dependency cleanup; version mismatch between the JTA provider and Hibernate's platform adapter.
Related errors
- Could not obtain TransactionManager from JtaPlatform
- UserTransaction reported transaction status as unknown
- Could not determine transaction status
- TransactionManager reported transaction status as unknwon
- DdlTransactionIsolatorJtaImpl could not locate TransactionMa
AI-assisted analysis of hibernate/hibernate-orm@fad1729dce (2026-08-22).
Data as JSON: /api/errors/1d1457b0af70b225.
Report an issue: GitHub.