[jboss-jira] [JBoss JIRA] (WFLY-10258) Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew

[Tom Jenkinson (Jira)]

    [ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662202#comment-13662202 ] 

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/java/org/jboss/tm/XAResourceWrapper.java 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}

> Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-10258
>                 URL: https://issues.jboss.org/browse/WFLY-10258
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Transactions
>    Affects Versions: 12.0.0.Final
>            Reporter: Jörg Bäsner
>            Priority: Major
>              Labels: downstream_dependency
>
> Scenario:
> - server-1 (intermediary)
> -- Running standalone profile
> -- Has a remote-outbound-connection pointing at server-2 through server-2's public IP address
> -- Intermediary bean need to lookup the Target bean in server-2 and also inject the {{TransactionManager}}
> -- Intermediary bean need to enlist a _dummy_ XAResource 
> - server-2 (target)
> -- disable {{JBOSS-LOCAL-USER}} auth
> -- Target bean needs to be annotated with {{@REQUIRES_NEW}} (important)
> - Standalone EJB client invokes an intermediary bean server-1, which as a result invokes target  bean on server-2. 
> The _dummy_ XAResource should log in the {{commit}} method whether one-phase optimization is being used like:
> {code}
>     @Override
>     public void commit(Xid arg0, boolean onePhaseOptim) throws XAException {
>         logger.info("-- Committing in the client resource. One-phase optimisation is: " + onePhaseOptim + " --"
>                 + (onePhaseOptim ? "" : " -> TWO-PHASE COMMIT !!!"));
>     }
> {code}
> In this scenario it is expected that the one-phase optimization is being used!



--
This message was sent by Atlassian Jira
(v7.12.1#712002)