[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