12:27 p.m.
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(a)redhat.com
<mailto:david.lloyd@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...
[2]
https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org...
[2] (raw)
https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/mai...
[3] for a list, see:
https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org...
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
- DML