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

David M. Lloyd david.lloyd at redhat.com
Tue Feb 2 08:49:57 EST 2016


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/arjuna/ats/internal/jts/orbspecific/interposition/resources/arjuna/ServerTopLevelAction.java#L121
> 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 at redhat.com
> <mailto:david.lloyd at 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 at redhat.com <mailto:david.lloyd at redhat.com>
>             <mailto: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>
>             <mailto:wildfly-dev at lists.jboss.org
>             <mailto:wildfly-dev at lists.jboss.org>>
>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
>
>     --
>     - DML
>
>

-- 
- DML


More information about the wildfly-dev mailing list