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

No problem :) On 2 February 2016 at 13:49, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: > Ah okay, cool. This is an easy (and, in hindsight, rather obvious) > enhancement that I can build into the new protocol with a minimum of effort. > > Thanks! > > On 02/02/2016 03:01 AM, Tom Jenkinson wrote: > >> Hi David, >> >> I was referring to case 1 when the transaction is inflowed into a second >> server. For JTS the type of transaction we create is a >> ServerTopLevelAction and this in its ctor calls back to the remote server: >> >> https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com... >> If the transport can do that without the TMs assistance then that works >> for me :) >> >> I don't think we should optimize for case 2. The incidents where a >> transaction is created and not used should be really low. >> >> Thanks, >> Tom >> >> >> >> On 1 February 2016 at 15:43, David M. Lloyd <david.lloyd(a)redhat.com >> <mailto:david.lloyd@redhat.com>> wrote: >> >> I was thinking about this a bit. It seems to me that there are two >> "levels" of this that could be explored: >> >> 1. A transaction was made available to the server, but the EJB on >> the server does not use the caller's transaction context, so the EJB >> code never actually has to inflow the transaction. The EJB code >> would be able to make this determination without any help from the TM. >> >> 2. A transaction was made available, and the EJB resumed it, but no >> resources were actually enlisted, or perhaps resources were enlisted >> but not actually used, resulting in the same effect but relying on >> the TM to provide this information. >> >> I guess when you refer to a callback from Narayana, (2) is what >> you're referring to? When would this information be available? >> Maybe as some special result of suspending the transaction? >> >> >> On 01/29/2016 12:27 PM, David M. Lloyd wrote: >> >> 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> >> <mailto:david.lloyd@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> >> <mailto:wildfly-dev@lists.jboss.org >> <mailto:wildfly-dev@lists.jboss.org>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> >> >> -- >> - DML >> >> >> > -- > - DML >