Re: [wildfly-dev] Transactions requirement during the graceful shutdown

On Wed, Jul 6, 2016 at 9:37 AM, Wolf Fink <wfink(a)redhat.com&gt; wrote: - -> start Graceful shutdown Stuart, how does the EJB subsystem know that there is an outstanding transaction (the EJB call may have enlisted a resource during the call)? Is it our (ie the txn subsystem) responsibility to detect that there is an outstanding transaction and delay the shutdown until it completes or until the shutdown grace period elapses? --> end Graceful shutdown Mike - client call EJB2 in the same Tx > - maybe EJB2 is annotated with @RequiresNew and need to suspend Tx1 and > start a new one to succeed > My expectation and hope is that such scenario is possible to continue and > finish successfully. > Wolf > On Wed, Jul 6, 2016 at 1:00 AM, Stuart Douglas <stuart.w.douglas(a)gmail.com > > wrote: >> Local transaction creation has to be allowed during graceful shutdown. >> e.g. if a web request is in the process of running and it attempts to start >> a transaction this must be allowed (the core requirement of graceful >> shutdown is that requests that have already been accepted continue to run >> as normal). >>> The only case when transactions should be disallowed are remote >> transactions, such as remote EJB and CORBA, which I think should already be >> dealt with at the respective endpoints (in terms of disallowing new >> transaction creation). I think the main thing that needs consideration here >> is what to do with EJB requests that would otherwise be rejected that are >> part of an existing remote transaction. We probably need some way of >> identifying these requests and allowing them to proceed. >>> Stuart >>>>> On Mon, Jul 4, 2016 at 11:11 PM, Gytis Trikleris <gtrikler(a)redhat.com>> wrote: >>>> Hello, >>>>> I’m in the process of writing an analysis document for >>> https://issues.jboss.org/browse/EAP7-459 and need your input. >>> Specifically I’m looking for the list of subsystems which might need to >>> create new transactions during the graceful shutdown. Normally new >>> transactions would not be allowed then, but this might stop other >>> subsystems to shutdown properly. If such subsystems exist we’ll need to >>> think of the way how to filter out their requests (e.g. providing SPI for >>> them). >>>>> Thanks, >>> Gytis >>> _______________________________________________ >>> 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 >> _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Michael Musgrove Transactions Team e: mmusgrov(a)redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)