[
https://issues.jboss.org/browse/WFLY-4937?page=com.atlassian.jira.plugin....
]
Jason Greene commented on WFLY-4937:
------------------------------------
Hi [~tomjenkinson],
Do you mean pausing existing distributed transactions? That's an interesting point to
consider. IMO it seems reasonable to allow an existing distributed transaction to prepare
+ commit/rollback. However, interesting things happen if additional data modification
changes originating from the external node happen on the suspended node as part of the
overall work of that distributed transaction. They won't be allowed to proceed, so I
imagine the transaction will rollback.
More explicitly I mean something like:
server A starts transaction
server A writes to local resource AR
server A calls server B's ejb doStuff
server B's doStuff writes to local resource BR and returns
server B is suspended
server A calls server B's ejb doOtherStuff
server B rejects the call throwing an exception
server A rolls the transaction back
resource AR changes are reverted
resource BR changes are reverted, even though the node is suspended
Implement graceful shutdown for transactions
--------------------------------------------
Key: WFLY-4937
URL:
https://issues.jboss.org/browse/WFLY-4937
Project: WildFly
Issue Type: Feature Request
Components: Transactions
Affects Versions: 10.0.0.Alpha5
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Fix For: 11.0.0.Alpha1
We will handle suspend for JTA and JTS by disallowing new transactions and then block the
suspend thread until the count of active transactions drops to zero. We will also suspend
the recovery manager.
We will *not* do graceful shutdown for the optional XTS subsystem. For example an
incoming XTS request for an existing transaction will be blocked.
Question: should we
- raise a new JIRA for this XTS case;
- document the deficiency and see if there are complaints;
- document the deficiency and fix it in a subsequent release
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)