-
Bug
-
Resolution: Done
-
Major
-
None
When scaling down pods it is possible for transactions to remain in their prepared state, we need to support the ability to recover these transactions and either commit or rollback the transaction.
We can use the approach already used within A-MQ to migrate messages on scale down, this allows an associated container to recover the transactions and attempt to complete them.
Note that this is not intended to address scaling down of servers with subordinate transactions (e.g. JTS or JBoss Remoting) as per CLOUD-2262 that is not yet tested or supported.
- causes
-
CLOUD-2244 [JDG] Broken backward compatibility after moving to SPLIT_DATA env var
-
- Verified
-
- is cloned by
-
CLOUD-2242 Support transaction recovery on scaling down of pods
-
- Closed
-
- is documented by
-
CLOUD-2239 [EAP] Check that A-MQ resources are recovered on scaling down of pods
-
- New
-
-
CLOUD-2238 Document the manual procedure for resolving in doubt transactions
-
- New
-
- is incorporated by
-
CLOUD-2243 Sprint 13 release
-
- Closed
-
- is related to
-
CLOUD-2248 Transaction recovery in migration pod sometimes doesn't remove orphans
-
- New
-
- relates to
-
CLOUD-2236 [EAP] Verify clean pod termination on scale down for tx recovery
-
- New
-
-
CLOUD-2261 [EAP][XA][Recovery][NFS] split lock is broken after a minute of network partition
-
- Closed
-
-
CLOUD-2223 EAP Transaction subsystem JDBC store tables should be prefixed with the node name
-
- Closed
-