8:45 p.m.
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/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:
>
> - 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev