[jboss-jira] [JBoss JIRA] (WFLY-10258) Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
Ondra Chaloupka (JIRA)
issues at jboss.org
Thu Apr 19 08:49:03 EDT 2018
[ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13563733#comment-13563733 ]
Ondra Chaloupka edited comment on WFLY-10258 at 4/19/18 8:48 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 run at 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.
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 the second server 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 second server 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 to. 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 run at 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.
> 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
>
> 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.5.0#75005)
More information about the jboss-jira
mailing list