[ https://issues.jboss.org/browse/JBTM-2997?page=com.atlassian.jira.plugin.... ] Michael Musgrove edited comment on JBTM-2997 at 10/29/18 8:14 AM: ------------------------------------------------------------------ Here are some notes I added about different coordinators accessing the same LRA record: Up until the time that the state moves to Compensating/Compensated anyone should be able to update an LRA record. After that we need to assign an owner (ie the coordinator that is driving the termination phase) and there needs to be a component that monitors that owners progress (assigning a new owner if it it fails). I don't think we need to worry about things like network partitions since the participant callbacks are meant to be idempotent. In recovery scenarios I would just write a timestamp into the record on each recovery pass and monitor that. In fact the presence of that timestamp would imply that there is a current owner and other coordinators need to leave it alone and only take over if it stops being updated. Note that before the end phase starts any coordinator is allowed to update the (shared) log and we should definitely consider LockReccord/STM for that purpose. To reiterate, an owner is assigned only when the termination phase of the protocol starts. If any another coordinator sees that the LRA is owned it should monitor the progress and if it sees that the current owner is not updating the timestamp it should (forcibly) takes ownership of the LRA. Furthermore, since an owner is assigned only when the end phase begins there should be no more join requests nor close or cancel requests and if there are then any coordinator can return an error back to the requester. We could also consider writing the owners id into the log as well as the timestamp to avoid potential race conditions. was (Author: mmusgrov): Here are some notes I added about different coordinators accessing the same LRA record: Up until the time that the state moves to Compensating/Compensated anyone should be able to update an LRA record. After that we need to assign an owner (ie the coordinator that is driving the termination phase) and there needs to be a component that monitors that owners progress (assigning a new owner if it it fails). I don't think we need to worry about things like network partitions since the participant callbacks are meant to be idempotent. In recovery scenarios I would just write a timestamp into the record on each recovery pass and monitor that. In fact the presence of that timestamp would imply that there is a current owner and other coordinators need to leave it alone and only take over if it stops being updated. Since STM/LockRecords ought to work for all store types I think we should definitely consider their use. -- This message was sent by Atlassian Jira (v7.12.1#712002)