[wildfly-dev] The EJB client and remote JTA transaction propagation
Tom Jenkinson
tom.jenkinson at redhat.com
Fri Jan 29 11:42:53 EST 2016
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> 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
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160129/b3915314/attachment.html
More information about the wildfly-dev
mailing list