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

[David M. Lloyd]

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 at redhat.com
> <mailto:david.lloyd at 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/jboss/ejb/client/annotation/ClientTransaction.java
>     [2]
>     https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>     [2] (raw)
>     https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>     [3] for a list, see:
>     https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client/annotation
>
>     --
>     - DML
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


-- 
- DML