[wildfly-dev] Transactions requirement during the graceful shutdown

[Stuart Douglas]

The transaction subsystem is going to have to handle that (with some help
from the EJB subsystem).

Stuart

On Mon, Jul 25, 2016 at 7:45 PM, Michael Musgrove <mmusgrov at redhat.com>
wrote:

>
>
> On Wed, Jul 6, 2016 at 9:37 AM, Wolf Fink <wfink at redhat.com> wrote:
>
>> Also I expect EJB chains working, I mean the following sequences
>> - remote->EJB (@NotSupported @Supports - no Tx started) -> internal EJB
>> (no matter whether called via Local/Remote interface) with @ReqNew or
>> @Required
>> - remote->EJB (any Tx started @Supports @Required @RequiresNew
>> @Mandatory) -> internal EJB (no matter whether called via Local/Remote
>> interface) @RequiresNew
>>
>> I'm not sure about this use-case with a client (no matter whether it is a
>> standalone app or another server)
>> - client starts a Tx
>> - client call EJB1 in Tx which return
>>
> - -> 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 at 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 at 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 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
>>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> Michael Musgrove
> Transactions Team
> e: mmusgrov at 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160725/d6b435ad/attachment.html