Re: [wildfly-dev] The EJB client and remote JTA transaction propagation

That's an interesting idea. So in effect, the remote EJB would tell the caller "you sent me a transaction ID, but in the end, I didn't use it"? I would need to think about how this might work in the presence of multiple concurrent invocations on the same transaction. Either way though, I think it would still be beneficial for clients to be able to explicitly annotate a client method (or otherwise establish a policy) such that it causes transactions to be propagated (or not), or to enforce transaction-related preconditions. The interceptor that implements this feature doesn't actually have protocol awareness: it just examines the current environment, and decides whether to attach the transaction to the invocation context. On 1/29/16 10:42 AM, Tom Jenkinson wrote: > One option that I would favour is to go down the JTS route where the > subordinate calls back on the parent to tell it to register it in the > transaction. This could be a new JBoss Remoting API that I can invoke > from Narayana. The call would not necessarily be a remote call, it would > invoke back into the JBR transport to tell it that when it returns to > the parent it needs to enlist (or not). > > On 29 January 2016 at 15:47, David M. Lloyd <david.lloyd(a)redhat.com > <mailto:david.lloyd@redhat.com>> wrote: > > As you may know, WildFly supports a feature wherein an EJB client > which > is invoking an EJB on a remote server has the option to propagate its > local transaction to the remote server, treating the remote server > as a > subordinate and coordinating the transaction's two-phase commit among > the resultant graph of servers. This feature has always been > limited in > that, when enabled, transactions are always propagated, regardless of > the peer EJB's transaction policy, or of whether the peer even has a > transaction manager. > > So, for the invocation rework which I anticipate will be included in > WildFly 11, I've introduced a new client-side annotation intended > to be > associated with the EJB interface which informs the client library > what > to do for transaction propagation for that interface. In addition, I > intend to configuration strategies which will allow the default > mode to > be specified in various ways (per-thread, globally, and by target > interface/method all come to mind), for cases where the EJB's remote > interface cannot be easily modified for some reason. I expect to > also > broaden these configuration strategies to apply to all client-side > EJB > interface/methods configuration items [3]. > > The first part of this change is the addition of a new annotation > called > @ClientTransaction [1], which accepts as a value an enum called > ClientTransactionPolicy [2]. The latter specifies whether a local > transaction is required or forbidden for the method or interface, and > also specifies whether the transaction is propagated or not > propagated. > > I've added copious amounts of JavaDoc in order to establish > exactly what > the behavior of each mode is, as well as to specify how each mode > interacts with the various modules that are configured via the > standard > javax.ejb.TransactionAttributeType enum. > > [1] > > https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org... > > [2] > > https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org... > > [2] (raw) > > https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/mai... > > [3] for a list, see: > > https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org... > > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > >