<div dir="ltr">Hi David,<div><br></div><div>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:</div><div><a href="https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/resources/arjuna/ServerTopLevelAction.java#L121">https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/resources/arjuna/ServerTopLevelAction.java#L121</a> If the transport can do that without the TMs assistance then that works for me :)<br></div><div><br></div><div>I don't think we should optimize for case 2. The incidents where a transaction is created and not used should be really low.</div><div><br></div><div>Thanks,</div><div>Tom</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 1 February 2016 at 15:43, David M. Lloyd <span dir="ltr"><<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was thinking about this a bit. It seems to me that there are two "levels" of this that could be explored:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<div class="HOEnZb"><div class="h5"><br>
<br>
On 01/29/2016 12:27 PM, David M. Lloyd wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's an interesting idea. So in effect, the remote EJB would tell the<br>
caller "you sent me a transaction ID, but in the end, I didn't use it"?<br>
I would need to think about how this might work in the presence of<br>
multiple concurrent invocations on the same transaction.<br>
<br>
Either way though, I think it would still be beneficial for clients to<br>
be able to explicitly annotate a client method (or otherwise establish a<br>
policy) such that it causes transactions to be propagated (or not), or<br>
to enforce transaction-related preconditions. The interceptor that<br>
implements this feature doesn't actually have protocol awareness: it<br>
just examines the current environment, and decides whether to attach the<br>
transaction to the invocation context.<br>
<br>
On 1/29/16 10:42 AM, Tom Jenkinson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One option that I would favour is to go down the JTS route where the<br>
subordinate calls back on the parent to tell it to register it in the<br>
transaction. This could be a new JBoss Remoting API that I can invoke<br>
from Narayana. The call would not necessarily be a remote call, it would<br>
invoke back into the JBR transport to tell it that when it returns to<br>
the parent it needs to enlist (or not).<br>
<br>
On 29 January 2016 at 15:47, David M. Lloyd <<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a><br>
<mailto:<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>>> wrote:<br>
<br>
As you may know, WildFly supports a feature wherein an EJB client<br>
which<br>
is invoking an EJB on a remote server has the option to propagate its<br>
local transaction to the remote server, treating the remote server<br>
as a<br>
subordinate and coordinating the transaction's two-phase commit among<br>
the resultant graph of servers. This feature has always been<br>
limited in<br>
that, when enabled, transactions are always propagated, regardless of<br>
the peer EJB's transaction policy, or of whether the peer even has a<br>
transaction manager.<br>
<br>
So, for the invocation rework which I anticipate will be included in<br>
WildFly 11, I've introduced a new client-side annotation intended<br>
to be<br>
associated with the EJB interface which informs the client library<br>
what<br>
to do for transaction propagation for that interface. In addition, I<br>
intend to configuration strategies which will allow the default<br>
mode to<br>
be specified in various ways (per-thread, globally, and by target<br>
interface/method all come to mind), for cases where the EJB's remote<br>
interface cannot be easily modified for some reason. I expect to<br>
also<br>
broaden these configuration strategies to apply to all client-side<br>
EJB<br>
interface/methods configuration items [3].<br>
<br>
The first part of this change is the addition of a new annotation<br>
called<br>
@ClientTransaction [1], which accepts as a value an enum called<br>
ClientTransactionPolicy [2]. The latter specifies whether a local<br>
transaction is required or forbidden for the method or interface, and<br>
also specifies whether the transaction is propagated or not<br>
propagated.<br>
<br>
I've added copious amounts of JavaDoc in order to establish<br>
exactly what<br>
the behavior of each mode is, as well as to specify how each mode<br>
interacts with the various modules that are configured via the<br>
standard<br>
javax.ejb.TransactionAttributeType enum.<br>
<br>
[1]<br>
<br>
<a href="https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransaction.java" rel="noreferrer" target="_blank">https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransaction.java</a><br>
<br>
[2]<br>
<br>
<a href="https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java" rel="noreferrer" target="_blank">https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java</a><br>
<br>
[2] (raw)<br>
<br>
<a href="https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java" rel="noreferrer" target="_blank">https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java</a><br>
<br>
[3] for a list, see:<br>
<br>
<a href="https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client/annotation" rel="noreferrer" target="_blank">https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client/annotation</a><br>
<br>
<br>
--<br>
- DML<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
-- <br>
- DML<br>
</div></div></blockquote></div><br></div>