A correctness fix for JMS connection pooling: concurrently closing sessions of a pooled connection can no longer deadlock the pool, so a connection that fails asynchronously (for example an IBM MQ connection drop) is reliably detected and replaced.
ExtremeTransactions 6.0.119 hardens crash recovery (a sibling-branch atomicity residual is closed; a failed or dangerously-late commit-log write is now treated as a heuristic hazard rather than an incorrect rollback) and fixes JMS connection-pool reuse of a connection broken asynchronously (for example IBM MQ). It also adds LogCloud recovery-action auditing with a read-only viewer, and corrects cross-service recovery and Spring Boot 3.4 configuration. It is a drop-in replacement for earlier 6.0.x releases.
Two transaction-timeout correctness improvements: a fix so a doomed transaction reusing the same connection is now interrupted on every subsequent use, not just the first, plus a new opt-in option to bound a REQUIRES_NEW transaction's timeout to its suspended parent's remaining time. Also includes an SLF4J 2.x detection fix and a connection-pool idle-eviction regression fix.
forceConnectionIntoXaMode workaround on spec-compliant JMS
providers and on Oracle AQ 19c and later.
AI can generate a transaction manager in minutes. But can it recover correctly when the coordinator crashes between prepare and commit? That's where the real engineering begins.