[ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin... ] Ondra Chaloupka edited comment on WFLY-10258 at 4/19/18 8:51 AM: ----------------------------------------------------------------- I've just checked the issue and I would mark it as expected behavior in a way. First you I would expect that you will get the 1PC behavior if you switch the order of the operation in your bean at the {{server-1}}. If you: first call {{server-2}} and then enlist the {{dummy XAResource}} then you should observe the 1PC behaviour. In case that you first enlist the {{dummy XAResource}} and you then call the {{server-2}} then you will observe the 2PC behaviour. The transaction manager is not capable to decide what will be result of the operation while calling from server one to server two. The scenario is like * you call from {{server-1}} to {{server-2}} * the app server/transaction manager can see you are working with some XAResource (in this case it's a ejb remote call to the {{server-2}}) thus the remote call is enlisted into the transaction * the {{server-2}} makes some operations (writing data to a database, it can make the operations in a completely new transaction too ({{REQUIRES_NEW}}) but the {{server-1}} does not know if there were some actions provided or not up to the time the {{prepare}} call is executed for the {{ejb remote XAResoruce}} at the {{server-1}} * you enlist {{dummy XAResource}} * the business method ends and transaction manager starts with the 2PC * transaction manager can see there are two XAResources to process, it starts with the first one, transaction manager calls {{ejb remote XAResource.prepare}} while there was no data manipulation (or no XAResource enlisted) at the {{server-2}} (as all work was done in a new transaction) thus the correct return code {{TwoPhaseOutcome.PREPARE_READONLY)}} is returned * the transaction manager wants to run {{dummy XAResource.prepare}} but it spot it's working with the first, and the only one, resource at the list (the previous one was skipped) - thus 1PC is applied and the {{dummy XAResource}} is just committed. On the other hand in case if {{dummy XAResource}} is in order as the first participant the transaction manager can see there are two resources in the 2PC to process thus it has to call {{prepare}} on the first one and the {{dummy XAResource}} is prepared. Then the other resource {{ejb remote XAResource}} returns {{TwoPhaseOutcome.PREPARE_READONLY}} but the {{dummy}} one is already prepared. Anyway I would consider this as expected. was (Author: ochaloup): I've just checked the issue and I would mark it as expected behavior in a way. First you I would expect that you will get the 1PC behavior if you switch the order of the operation in your bean at the {{server-1}}. If you: first call {{server-2}} and then enlist the {{dummy XAResource}} then you should observe the 1PC behaviour. In case that you first enlist the {{dummy XAResource}} and you then call the {{server-2}} then you will observe the 2PC behaviour. The transaction manager is not capable to decide what will be result of the operation while calling from server one to server two. The scenario is like * you call from {{server-1}} to {{server-2}} * the app server/transaction manager can see you are working with some XAResource (in this case it's a ejb remote call to the {{server-2}}) thus the remote call is enlisted into the transaction * the {{server-2}} makes some operations (writing data to a database, it can make the operations in a completely new transaction too ({{REQUIRES_NEW}}) but the {{server-1}} does not know if there were some actions provided or not up to the time the {{prepare}} call is executed for the {{ejb remote XAResoruce}} at the {{server-1}} * you enlist {{dummy XAResource}} * the business method ends and transaction manager starts with the 2PC * transaction manager can see there are two XAResources to process, it starts with the first one, transaction manager calls {{ejb remote XAResource.prepare}} while there was no data manipulation (or no XAResource enlisted) at the {{server-2}} (as all work was done in a new transaction) thus the correct return code {{TwoPhaseOutcome.PREPARE_READONLY)}} is returned * the transaction manager wants to run {{dummy XAResource.prepare}} but it can it's in fact the first and only resource at the list (the previous one was skipped). There are no other resources thus 1PC is applied and the {{dummy XAResource}} is just committed. On the other hand in case if {{dummy XAResource}} is in order as the first participant the transaction manager can see there are two resources in the 2PC to process thus it has to call {{prepare}} on the first one and the {{dummy XAResource}} is prepared. Then the other resource {{ejb remote XAResource}} returns {{TwoPhaseOutcome.PREPARE_READONLY}} but the {{dummy}} one is already prepared. Anyway I would consider this as expected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)