[wildfly-dev] EJB Transactions Graceful Shutdown

[Flavia Rainone]

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.

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