allthingssecurity opened a new pull request, #27983: URL: https://github.com/apache/camel/pull/27983
# Description [CAMEL-25698](https://issues.apache.org/jira/browse/CAMEL-25698) In a `transacted()` route that runs with a JTA transaction manager, the camel-jta `TransactionErrorHandler` rolls the transaction back only when the exchange has an exception or `isRollbackOnly()` is true. `markRollbackOnlyLast()` sets only the rollback-only-last flag (no exception), and `isRollbackOnly()` does not include that flag (it has not since Camel 3). So the transaction policy saw a normal return and committed. Right after that, `processInTransaction` clears the flag and the exception, as it should for rollback only last, so nothing on the exchange showed that the rollback was skipped. CAMEL-17105 fixed the same condition in the camel-spring `TransactionErrorHandler`, which checks `exchange.getException() != null || exchange.isRollbackOnly() || exchange.isRollbackOnlyLast()`. The camel-jta copy of the class was not changed. CAMEL-25588 (merged this week) makes the SQL, MyBatis and jOOQ consumers honor rollback only last on the assumption that a `transacted()` block has already handled the flag. With camel-jta the block cleared the flag without rolling back. Change (`TransactionErrorHandler.doInTransactionTemplate`, one line): `exchange.isRollbackOnlyLast()` is added to the rollback condition, the same as in camel-spring. The flag and the exception are still cleared after the transaction, so an outer `transacted()` block does not see them. What users can notice: a JTA `transacted()` route that calls `markRollbackOnlyLast()` now rolls back that transaction. `markRollbackOnly()`, exceptions and routes that do neither behave as before. The 4.24 upgrade guide gets a short note next to the CAMEL-25588 entry. Tests: - New `TransactionErrorHandlerRollbackOnlyLastTest` (2 tests), with a `JtaTransactionPolicy` that records whether its `Runnable` returned (commit) or threw (rollback): - a `TransactionErrorHandler` around a processor that marks the exchange rollback only last: the transaction is rolled back and not committed, and the flag and the exception are cleared afterwards; - a route `from("direct:start").transacted("recordingPolicy").setBody(constant("done")).markRollbackOnlyLast()`: the transaction is rolled back and the exchange has no exception. - Without the change (main's `TransactionErrorHandler`, same tests) both fail: `The transaction should be rolled back ==> expected: <1> but was: <0>`. - With the change the camel-jta unit tests pass: 7 run, 0 failures, 0 skipped. What is not changed: - The camel-spring `TransactionErrorHandler` already has this condition. - Other consumers that commit on their own (camel-jms and camel-sjms with `transacted=true`, camel-spring-rabbitmq, camel-nats, the camel-kafka transaction synchronization) check `isRollbackOnly()` but not `isRollbackOnlyLast()`. Whether they should follow CAMEL-25588 is a separate question, so it is left for another ticket. What was not run: the module's integration test (`TransactionErrorHandlerGracePeriodShutdownIT`, it needs a PostgreSQL container), and a real JTA transaction manager. The test uses a recording `JtaTransactionPolicy` in the same way as the existing `TransactionErrorHandlerShutdownTest`. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it): [CAMEL-25698](https://issues.apache.org/jira/browse/CAMEL-25698). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested camel-jta, including the formatter and import-sort plugins. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
