[wildfly-dev] The EJB client and remote JTA transaction propagation
Tom Jenkinson
tom.jenkinson at redhat.com
Tue Feb 2 04:01:25 EST 2016
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> 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>> 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>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>
>>
> --
> - DML
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160202/7f48fec2/attachment.html
More information about the wildfly-dev
mailing list