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

Tom Jenkinson tom.jenkinson at redhat.com
Tue Feb 2 09:27:45 EST 2016


No problem :)

On 2 February 2016 at 13:49, David M. Lloyd <david.lloyd at redhat.com> 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/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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160202/4320a736/attachment-0001.html 


More information about the wildfly-dev mailing list