[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