<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi Richard,</p>
<p>This is the corresponding Jira:
<a class="moz-txt-link-freetext" href="https://issues.jboss.org/browse/WFLY-7207">https://issues.jboss.org/browse/WFLY-7207</a><br>
</p>
<p>There is a document for transactions graceful shutdown here:
<a class="moz-txt-link-freetext" href="https://developer.jboss.org/wiki/DevAnalysisForTransactionsGracefulShutdown">https://developer.jboss.org/wiki/DevAnalysisForTransactionsGracefulShutdown</a></p>
<p>In a nutshell, the EJB system will not complete suspension until
all open transactions are concluded, and that includes
XATransactions.</p>
<p>This issue you're mentioning involving EJB client retry plus
remote transactions is possibly outside the scope of WFLY-7207. Do
you have a Jira for that one? If I understand correctly, the
problem is that the client shouldn't retry at the original XA
node, because that node has shutdown, is that correct? In this
case, I find it weird, because the ejb client is going to be
notified that the client is no longer available on shutdown, thus
preventing the client from invoking that node, as Stuart mentioned
in his previous e-mail. We are going to have to workaround that
mechanism, by delaying the client notification until all
transactions are complete. As this behavior could be undesired,
after all it would make invocations to the shutting down node
possible while there are open transactions in that node, we are
going to make it configurable, the user might not want graceful
ejb transaction at all in this case.</p>
<p>Or maybe you mean that all remote invocations belonging to the
same remote transaction should always be answered by the same
cluster node?<br>
</p>
<p>Regarding your consideration, yes, you are correct, this feature
is to give an oportunity for open transactions to complete before
shutdown. I think Stuart has plans of extending the graceful
shutdown feature to cover undeployments in the future.<br>
</p>
<p>R.<br>
</p>
<p>Flavia<br>
</p>
<br>
<div class="moz-cite-prefix">On 02-12-2016 17:45, Richard
Achmatowicz wrote:<br>
</div>
<blockquote
cite="mid:759f6185-ad7b-f900-8cc5-65e6fb023f66@redhat.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<p>Another consideration ... but this may be outside the scope of
what you are working on.</p>
<p>I assume that by "graceful shutdown for ejb transactions" you
mean a feature to allow ejb transactions, which have been
initiated before a shutdown, to be given a reasonable chance to
complete after shutdown has been initiated, and so avoiding
aborting a transaction just because a shutdown was initiated at
an inappropriate time. In other words, the feature is specific
to the case of when the server is being shutdown
cleanly/gracefully. It's worht mentioning that in addition to
shutdown of the server, undeploying a deployment containing ejbs
(in the middle of a transaction) is going to have a similar
negative impact on ejb transactions as initiating a shutdown.
Also, if the deployment is clustered, there are possibilities
for retrying on another available node; but as I mentioned
before, there are issues with that too. <br>
</p>
<p>Just to say that "graceful shutdown" has different meanings in
different deployment contexts.<br>
</p>
Richard<br>
<div class="moz-cite-prefix">On 02/12/16 01:29 PM, Richard
Achmatowicz wrote:<br>
</div>
<blockquote
cite="mid:f0e1121b-de9d-404d-9abb-f1d73998cafd@redhat.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=windows-1252">
<p>Hi Flavia</p>
<p>Is there any overall design for this feature available to
browse? For example, there has long been a problem (and still
is) with remotely initiated transactions and the EJB client
retry mechanism (both of them) which associates an XA resource
with one node at the beginning of the transaction and then
retries on another, completes on the other, then tries to
commit on the original XA node which has shutdown. This is
anything but clean.<br>
</p>
<p>Richard<br>
</p>
<br>
<div class="moz-cite-prefix">On 02/12/16 11:56 AM, Flavia
Rainone wrote:<br>
</div>
<blockquote
cite="mid:7cfd743c-e1a5-d59a-b33b-f9541cbdc6b1@redhat.com"
type="cite">
<p>Hi,</p>
<p>I'm creating this thread to discuss the remaining details
of graceful shutdown for ejb transactions.</p>
<p>This is more or less what I've done so far:</p>
<p><a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760">https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760</a></p>
<p>While discussing this in the hip chat yesterday, Stuart
mentioned that maybe we could have the transactions
subsystem responsible for keeping track of how many active
transactions we have, instead of putting that code in
EjbRemoteTransactionsRepository. <br>
</p>
<p>Stuart, does that include having the suspend callback being
done at transactions subsystem as well? I'm thinking maybe
not, because there are two points in the ejb subsystem we
need to know if transactions suspension is over:</p>
<p>- at EjbSuspendInterceptor if it is over, no request is
allowed, if it is not over, we need to check if current
invocation contains a reference to an active transaction</p>
<p>- at some point, we need to let control point notify that
the ejb module is no longer available to ejb client after
transaction suspension is over, i.e., we need to do that
when suspend has been requested and there are no remaining
active transactions available.</p>
<p>On the other hand, it is hard to draw the line between what
should be in the transactions subsystem and what shouldn't.
If the callback is done at transactions subsystem, we need a
way of having ejb3 notified that it is done. If it is not
done at transactions subsystem, ejb3 has to be notified of
the active transactions going to zero, which seems a lot of
overhead, so from this point of view maybe the callback
should be in the transactions system after all.<br>
</p>
Stuart and Gytis, any thoughts?<br>
<pre class="moz-signature" cols="72">--
Flavia Rainone
Principal Software Engineer
JBoss EAP/WildFly Team
M: (+55) 11 981-225-466
Red Hat.
Better technology.
Faster innovation.
Powered by community collaboration.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
wildfly-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
wildfly-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
wildfly-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Flavia Rainone
Principal Software Engineer
JBoss EAP/WildFly Team
M: (+55) 11 981-225-466
Red Hat.
Better technology.
Faster innovation.
Powered by community collaboration.
</pre>
</body>
</html>