My understanding would be that the EJB transport would detect the transaction.commit call (although it should have an outstanding EJB call so I don't think that it would be possible for a client to call commit) and throw an exception. It could be that EJB transport would register a synchronization beforeCompletion to do this.

On 9 February 2016 at 14:41, David M. Lloyd <> wrote:
I have a follow-up question about delaying enlistment (I'm getting to this point in the code).

I'm worried about a scenario wherein the subordinate server begins the transaction, does some work in the EJB, and then tries to return, but the connection to the server has been partitioned indefinitely.  The server *may* opt to continue and commit the transaction despite the subordinate failure, in which case the subordinate, not receiving any control messages from the root coordinator, would roll back the transaction at the timeout, while the server (not knowing about the subordinate server) would continue and commit the transaction, not knowing what work (if any) the subordinate server had performed.

Is this a real problem?  Perhaps I do need an "enlist me" callback to the server after all, which executes before the EJB imports and resumes the subordinate transaction?

On 02/02/2016 08:27 AM, Tom Jenkinson wrote:
No problem :)

On 2 February 2016 at 13:49, David M. Lloyd <> 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.


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:
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.


On 1 February 2016 at 15:43, David M. Lloyd <
<>> 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
         implements this feature doesn't actually have protocol awareness:
         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
             < <>

             <>>> wrote:

                  As you may know, WildFly supports a feature wherein an
             EJB client
                  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
                  to do for transaction propagation for that interface.
             In addition, I
                  intend to configuration strategies which will allow the
             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
                  broaden these configuration strategies to apply to all
                  interface/methods configuration items [3].

                  The first part of this change is the addition of a new
                  @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

                  I've added copious amounts of JavaDoc in order to
             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
                  javax.ejb.TransactionAttributeType enum.



                  [2] (raw)

                  [3] for a list, see:

                  - DML
                  wildfly-dev mailing list

     - DML