What causes "Error performing work" in hibernate/hibernate-orm?

Inspect exception.getCause() and exception.getSuppressed() - the actual SQL/TM error lives there, not on the wrapper

hibernate/hibernate-orm · error · HibernateException

Error performing work

Error message

Error performing work

What it means

doInNewTransaction runs the isolated work and then commits; if callable.call() or transactionManager.commit() throws anything that is not a HibernateException, it is wrapped as 'Error performing work'. Before rethrowing, Hibernate rolls the isolated transaction back, and if that rollback fails the rollback failure is attached via addSuppressed. The real failure is therefore in getCause() (and possibly getSuppressed()), not on this wrapper.

Source

Thrown at hibernate-core/src/main/java/org/hibernate/resource/transaction/backend/jta/internal/JtaIsolationDelegate.java:174

			transactionManager.begin();
		}
		catch ( SystemException | NotSupportedException exception ) {
			throw new TransactionException( "Unable to start isolated transaction", exception );
		}

		try {
			T result = callable.call();
			// if everything went ok, commit the isolated transaction
			transactionManager.commit();
			return result;
		}
		catch ( Exception exception ) { //TODO: should this be Throwable
			rollBack( transactionManager, exception );
			if ( exception instanceof HibernateException he ) {
				throw he;
			}
			else {
				throw new HibernateException( "Error performing work", exception );
			}
		}
	}

	private static void rollBack(TransactionManager transactionManager, Exception original) {
		try {
			transactionManager.rollback();
		}
		catch ( Exception exception ) {
			JTA_LOGGER.unableToRollBackIsolatedTransaction( original, exception );
			original.addSuppressed( exception );
		}
	}

	private <T> T doTheWork(WorkExecutorVisitable<T> work) {
		final Connection connection;
		try {
			// obtain our isolated connection

View on GitHub (pinned to fad1729dce)

Solutions

Inspect exception.getCause() and exception.getSuppressed() - the actual SQL/TM error lives there, not on the wrapper
Fix the underlying problem identified by the cause (missing object, constraint violation, lock wait)
For heuristic causes, resolve the TransactionManager transaction store and resource-manager logs
Retry once transient TM/lock conditions have cleared

Defensive patterns

Strategy: try-catch

Try / catch

catch (HibernateException e) {
    Throwable cause = e.getCause() != null ? e.getCause() : e;
    for (Throwable s : e.getSuppressed()) {
        log.error("rollback of isolated transaction also failed", s);
    }
    // handle 'cause' (the SQL / JTA commit error), not the wrapper
}

Prevention

Treat this wrapper as a cause-carrier: always log getCause() and getSuppressed() first
Validate that schema objects used by isolated work exist before enabling the feature
Keep isolated work small so commit failures are easier to attribute

When it happens

Trigger: A RuntimeException escaping work executed inside a new JTA transaction via IsolationDelegate (transacted=true), or commit() of the isolated transaction failing with RollbackException, HeuristicMixedException, HeuristicRollbackException or SystemException.

Common situations: Isolated schema or generator work hitting SQL/lock errors; the isolated transaction marked rollback-only by the TM (lock timeout) and failing at commit; XA heuristic outcomes after a resource-manager crash.

Related errors

AI-assisted analysis of hibernate/hibernate-orm@fad1729dce (2026-08-22). Data as JSON: /api/errors/f16a3e1125250eb4. Report an issue: GitHub.