[ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin... ] Tom Jenkinson commented on WFLY-10258: -------------------------------------- I was meaning that by delaying the sort until the point where you will can make a reasonable understanding of whether you will be able to return RDONLY and therefore can't get inconsistent behaviour at that particular point. The implementation would be as follows: {code} public int compareTo(OtherEJBRemoteResource) { if (I know I am going to return RDONLY from prepare) if (OtherEJBRemoteResource is not going to return RDONLY from prepare) return -1 else if (OtherEJBRemoteResource knows it is going to return RDONLY from prepare) return 1 return 0 // you don't know that you are going to return RDONLY from prepare so can't execute the 1PC optimization {code} That basically relies on the fact that the knowledge you are definitely RDONLY doesn't change between the time the transaction manager calls xa_end and the time it calls xa_prepare during the 2PC process which was an assumption (to get the benefit) of JBTM-3020. I do acknowledge that the comparison would change up to that point of this lifecyle so perhaps it is safer to add a method on https://github.com/jbosstm/jboss-transaction-spi/blob/master/src/main/jav... to provide a sortable reference (a bit closer to JBTM-3020) in case some other library sorts these references rather than Narayana at this particular point. {code} SortableXAResource getSortableReference () { if (I am RDONLY) { return SortableReference(true, this); else { return SortableReference(false, this); } private class SortableReference implements Comparator { boolean definitelyRDONLY; XAResourceWrapper instanceToInvokeOn; public int compareTo(OtherSortableReference ) { if (definitelyRDONLY) if (!OtherSortableReference.definitelyRDONLY) return -1 else if (OtherSortableReference.definitelyRDONLY) return 1 return 0 } } {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)