<div dir="ltr">No problem :)</div><div class="gmail_extra"><br><div class="gmail_quote">On 2 February 2016 at 13:49, 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">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.<br>
<br>
Thanks!<span class=""><br>
<br>
On 02/02/2016 03:01 AM, Tom Jenkinson wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Hi David,<br>
<br>
I was referring to case 1 when the transaction is inflowed into a second<br>
server. For JTS the type of transaction we create is a<br>
ServerTopLevelAction and this in its ctor calls back to the remote server:<br>
<a href="https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/resources/arjuna/ServerTopLevelAction.java#L121" rel="noreferrer" target="_blank">https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/resources/arjuna/ServerTopLevelAction.java#L121</a><br>
If the transport can do that without the TMs assistance then that works<br>
for me :)<br>
<br>
I don't think we should optimize for case 2. The incidents where a<br>
transaction is created and not used should be really low.<br>
<br>
Thanks,<br>
Tom<br>
<br>
<br>
<br>
On 1 February 2016 at 15:43, David M. Lloyd <<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a><br></span><div><div class="h5">
<mailto:<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>>> wrote:<br>
<br>
I was thinking about this a bit. It seems to me that there are two<br>
"levels" of this that could be explored:<br>
<br>
1. A transaction was made available to the server, but the EJB on<br>
the server does not use the caller's transaction context, so the EJB<br>
code never actually has to inflow the transaction. The EJB code<br>
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<br>
resources were actually enlisted, or perhaps resources were enlisted<br>
but not actually used, resulting in the same effect but relying on<br>
the TM to provide this information.<br>
<br>
I guess when you refer to a callback from Narayana, (2) is what<br>
you're referring to? When would this information be available?<br>
Maybe as some special result of suspending the transaction?<br>
<br>
<br>
On 01/29/2016 12:27 PM, David M. Lloyd wrote:<br>
<br>
That's an interesting idea. So in effect, the remote EJB would<br>
tell the<br>
caller "you sent me a transaction ID, but in the end, I didn't<br>
use it"?<br>
I would need to think about how this might work in the<br>
presence of<br>
multiple concurrent invocations on the same transaction.<br>
<br>
Either way though, I think it would still be beneficial for<br>
clients to<br>
be able to explicitly annotate a client method (or otherwise<br>
establish a<br>
policy) such that it causes transactions to be propagated (or<br>
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<br>
attach the<br>
transaction to the invocation context.<br>
<br>
On 1/29/16 10:42 AM, Tom Jenkinson wrote:<br>
<br>
One option that I would favour is to go down the JTS route<br>
where the<br>
subordinate calls back on the parent to tell it to register<br>
it in the<br>
transaction. This could be a new JBoss Remoting API that I<br>
can invoke<br>
from Narayana. The call would not necessarily be a remote<br>
call, it would<br>
invoke back into the JBR transport to tell it that when it<br>
returns to<br>
the parent it needs to enlist (or not).<br>
<br>
On 29 January 2016 at 15:47, David M. Lloyd<br>
<<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a> <mailto:<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>><br></div></div>
<mailto:<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a><div><div class="h5"><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<br>
EJB client<br>
which<br>
is invoking an EJB on a remote server has the option to<br>
propagate its<br>
local transaction to the remote server, treating the<br>
remote server<br>
as a<br>
subordinate and coordinating the transaction's<br>
two-phase commit among<br>
the resultant graph of servers. This feature has<br>
always been<br>
limited in<br>
that, when enabled, transactions are always propagated,<br>
regardless of<br>
the peer EJB's transaction policy, or of whether the<br>
peer even has a<br>
transaction manager.<br>
<br>
So, for the invocation rework which I anticipate will<br>
be included in<br>
WildFly 11, I've introduced a new client-side<br>
annotation intended<br>
to be<br>
associated with the EJB interface which informs the<br>
client library<br>
what<br>
to do for transaction propagation for that interface.<br>
In addition, I<br>
intend to configuration strategies which will allow the<br>
default<br>
mode to<br>
be specified in various ways (per-thread, globally, and<br>
by target<br>
interface/method all come to mind), for cases where the<br>
EJB's remote<br>
interface cannot be easily modified for some reason. I<br>
expect to<br>
also<br>
broaden these configuration strategies to apply to all<br>
client-side<br>
EJB<br>
interface/methods configuration items [3].<br>
<br>
The first part of this change is the addition of a new<br>
annotation<br>
called<br>
@ClientTransaction [1], which accepts as a value an<br>
enum called<br>
ClientTransactionPolicy [2]. The latter specifies<br>
whether a local<br>
transaction is required or forbidden for the method or<br>
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<br>
each mode<br>
interacts with the various modules that are configured<br>
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><br>
<mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>><br></div></div>
<mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><span class=""><br>
<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>
<br>
<br>
<br>
--<br>
- DML<br>
<br>
<br>
</span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
-- <br>
- DML<br>
</font></span></blockquote></div><br></div>