[wildfly-dev] EJB Transactions Graceful Shutdown

Flavia Rainone frainone at redhat.com
Mon Dec 5 13:46:03 EST 2016


Hi Richard,

This is the corresponding Jira: https://issues.jboss.org/browse/WFLY-7207

There is a document for transactions graceful shutdown here: 
https://developer.jboss.org/wiki/DevAnalysisForTransactionsGracefulShutdown

In a nutshell, the EJB system will not complete suspension until all 
open transactions are concluded, and that includes XATransactions.

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.

Or maybe you mean that all remote invocations belonging to the same 
remote transaction should always be answered by the same cluster node?

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.

R.

Flavia


On 02-12-2016 17:45, Richard Achmatowicz wrote:
>
> Another consideration ... but this may be outside the scope of what 
> you are working on.
>
> 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.
>
> Just to say that "graceful shutdown" has different meanings in 
> different deployment contexts.
>
> Richard
> On 02/12/16 01:29 PM, Richard Achmatowicz wrote:
>>
>> Hi Flavia
>>
>> 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.
>>
>> Richard
>>
>>
>> On 02/12/16 11:56 AM, Flavia Rainone wrote:
>>>
>>> Hi,
>>>
>>> I'm creating this thread to discuss the remaining details of 
>>> graceful shutdown for ejb transactions.
>>>
>>> This is more or less what I've done so far:
>>>
>>> https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760
>>>
>>> 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.
>>>
>>> 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:
>>>
>>> - 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
>>>
>>> - 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.
>>>
>>> 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.
>>>
>>> Stuart and Gytis, any thoughts?
>>> -- 
>>> 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.
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161205/2e97d6f7/attachment.html 


More information about the wildfly-dev mailing list