[wildfly-dev] EJB Transactions Graceful Shutdown

[Richard Achmatowicz]

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

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