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

[ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin... ] Ondra Chaloupka edited comment on WFLY-10258 at 4/20/18 10:15 AM: ------------------------------------------------------------------ [~dmlloyd] a good point, agree and on top of it I can see you already implemented the functionality ;-P Anyway, if you permit a small side step: I think it would be a hard to involve your idea about using {{XAResource.end}} call to decide about the resource future. First the {{XAResource}} API is not providing way to return a value back to the caller (https://docs.oracle.com/javaee/7/api/javax/transaction/xa/XAResource.html...). The other issue is the Narayana implementation which calls the {{.end}} just before {{prepare}} call on the each {{XAResource}} (https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...). Refactoring the code and moving the {{end}} call to some top-level place where the decision about 1PC/2PC is done (https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...) I consider difficult. Back to the prior point: As I was investigating your point I can see that the wfly transactional client delists itself from the current transaction in {{beforeCompletion}} calllback when it knows there was no work done (https://github.com/wildfly/wildfly-transaction-client/blob/master/src/mai...). That's good but delisting at the Narayana side (https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...) seems not removing the xa resource from the list (https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...) which defines if 1PC is applied. {code} Thread [default task-2] (Suspended (breakpoint at line 129 in SubordinateXAResource)) owns: Object (id=531) SubordinateXAResource.end(Xid, int) line: 129 TransactionImple.delistResource(XAResource, int) line: 897 LocalTransaction.delistResource(XAResource, int) line: 162 XAOutflowedResources$1.beforeCompletion() line: 74 921870613.accept(Object) line: not available 1900321310.accept(Object, Object) line: not available LocalTransaction(AbstractTransaction).performConsumer(ExceptionBiConsumer<T,U,E>, T, U) line: 209 LocalTransaction(AbstractTransaction).performConsumer(ExceptionConsumer<T,E>, T) line: 220 AbstractTransaction$AssociatingSynchronization.beforeCompletion() line: 265 SynchronizationImple.beforeCompletion() line: 76 AtomicAction(TwoPhaseCoordinator).beforeCompletion() line: 368 AtomicAction(TwoPhaseCoordinator).end(boolean) line: 91 AtomicAction(AtomicAction).commit(boolean) line: 162 TransactionImple.commitAndDisassociate() line: 1289 TransactionManagerImple(BaseTransaction).commit() line: 126 TransactionManagerDelegate(BaseTransactionManagerDelegate).commit() line: 89 LocalTransaction.commitAndDissociate() line: 73 ContextTransactionManager.commit() line: 71 CMTTxInterceptor.endTransaction(Transaction) line: 88 CMTTxInterceptor.invokeInOurTx(InterceptorContext, EJBComponent) line: 261 CMTTxInterceptor.required(InterceptorContext, EJBComponent, int) line: 362 CMTTxInterceptor.processInvocation(InterceptorContext) line: 144 InterceptorContext.proceed() line: 422 {code} */edit* I found the started discussion at the forum: https://developer.jboss.org/message/982119 was (Author: ochaloup): [~dmlloyd] a good point, agree and on top of it I can see you already implemented the functionality ;-P Anyway, if you permit a small side step: I think it would be a hard to involve your idea about using {{XAResource.end}} call to decide about the resource future. First the {{XAResource}} API is not providing way to return a value back to the caller (https://docs.oracle.com/javaee/7/api/javax/transaction/xa/XAResource.html...). The other issue is the Narayana implementation which calls the {{.end}} just before {{prepare}} call on the each {{XAResource}} (https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...). Refactoring the code and moving the {{end}} call to some top-level place where the decision about 1PC/2PC is done (https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...) I consider difficult. Back to the prior point: As I was investigating your point I can see that the wfly transactional client delists itself from the current transaction in {{beforeCompletion}} calllback when it knows there was no work done (https://github.com/wildfly/wildfly-transaction-client/blob/master/src/mai...). That's good but delisting at the Narayana side (https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...) seems not removing the xa resource from the list (https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...) which defines if 1PC is applied. */edit* I found the started discussion at the forum: https://developer.jboss.org/message/982119 -- This message was sent by Atlassian JIRA (v7.5.0#75005)