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

            <>>> 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 not

                 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
                 javax.ejb.TransactionAttributeType enum.





                 [2] (raw)


                 [3] for a list, see:


                 - DML
                 wildfly-dev mailing list

    - DML