4:39 p.m.
On Sat, Dec 3, 2016 at 3:40 AM, Flavia Rainone <frainone(a)redhat.com> 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/7017146522af9a979a8a8e0c92039e6a...
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:
No, that still has to be handled at an EJB subsystem level.
Conceptually this is similar to what was done for the XTS subsytem, so
it should probably use a similar design. Ideally while the server is
in the running state the only graceful related code that is run is the
control point request tracking, however this may not be possible.
One other thing that came up on our hipchat discussion yesterday is TX
level graceful shutdown actually has some significant drawbacks, as
you cannot send out the module unavailability message until all the
transactions have been closed. This means that while we are waiting
for transactions to complete the node will still be part of a cluster,
and clients will send it requests that will be immediately rejected.
Stuart
- 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
not 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.