Transactions requirement during the graceful shutdown

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Transactions requirement during the graceful shutdown

Gytis Trikleris-2
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transactions requirement during the graceful shutdown

Stuart Douglas
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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transactions requirement during the graceful shutdown

Wolf-Dieter Fink
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
- 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transactions requirement during the graceful shutdown

Stuart Douglas

This works fine at the moment, anything that stopped this I would consider to be a regression.

Stuart


On Wed, 6 Jul 2016, 18:37 Wolf Fink <[hidden email]> 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
- 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transactions requirement during the graceful shutdown

Michael Musgrove
In reply to this post by Stuart Douglas


On Wed, Jul 6, 2016 at 12:00 AM, Stuart Douglas <[hidden email]> 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.

Such requests will result in us creating a subordinate transaction on the shutting down server. If we allow these requests then we may never be able to shut down the transaction system but on the other hand if there isn't much traffic then we should allow the remote transaction to continue. Therefore I think we should make the behaviour configurable.

Mike 
 

Stuart



On Mon, Jul 4, 2016 at 11:11 PM, Gytis Trikleris <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Michael Musgrove
Transactions Team
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)

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transactions requirement during the graceful shutdown

Gytis Trikleris-2
In reply to this post by Stuart Douglas
Sounds that we shouldn’t do extra shutdown logic for JTA and JTS other than possibly provide SPI for EJB and CORBA? 

Gytis

On 6 Jul 2016, at 01:00, Stuart Douglas <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transactions requirement during the graceful shutdown

Michael Musgrove
If a remote server has created a transaction and made an ejb call into the shutting down server then initially our (CORBA) interceptors will trigger and we will create a subordinate transaction and put that on the thread. So provided the EJB subsystem checks the association and lets the request through if it finds a transaction then we will be covered. Does the EJB subsystem perform this check?

On Thu, Jul 7, 2016 at 11:02 AM, Gytis Trikleris <[hidden email]> wrote:
Sounds that we shouldn’t do extra shutdown logic for JTA and JTS other than possibly provide SPI for EJB and CORBA? 

Gytis

On 6 Jul 2016, at 01:00, Stuart Douglas <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Michael Musgrove
Transactions Team
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)

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transactions requirement during the graceful shutdown

Stuart Douglas
Not at the moment.

Stuart

On Tue, Jul 12, 2016 at 11:38 PM, Michael Musgrove <[hidden email]> wrote:
If a remote server has created a transaction and made an ejb call into the shutting down server then initially our (CORBA) interceptors will trigger and we will create a subordinate transaction and put that on the thread. So provided the EJB subsystem checks the association and lets the request through if it finds a transaction then we will be covered. Does the EJB subsystem perform this check?

On Thu, Jul 7, 2016 at 11:02 AM, Gytis Trikleris <[hidden email]> wrote:
Sounds that we shouldn’t do extra shutdown logic for JTA and JTS other than possibly provide SPI for EJB and CORBA? 

Gytis

On 6 Jul 2016, at 01:00, Stuart Douglas <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Michael Musgrove
Transactions Team
t: <a href="tel:%2B44%20191%20243%200870" value="+441912430870" target="_blank">+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)


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transactions requirement during the graceful shutdown

Michael Musgrove
In reply to this post by Wolf-Dieter Fink


On Wed, Jul 6, 2016 at 9:37 AM, Wolf Fink <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Michael Musgrove
Transactions Team
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)

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:


On Wed, Jul 6, 2016 at 9:37 AM, Wolf Fink <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Michael Musgrove
Transactions Team
t: <a href="tel:%2B44%20191%20243%200870" value="+441912430870" target="_blank">+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)


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transactions requirement during the graceful shutdown

Michael Musgrove
OK thank you for all your input on this task and I think we have enough to go on in order to proceed with JTA/JTS.

But let's keep this thread open for the XTS support for the feature (we did have an earlier private email thread with subject "“XTS impact on suspend/resume” which was inconclusive).

Mike

On Mon, Jul 25, 2016 at 11:36 AM, Stuart Douglas <[hidden email]> wrote:
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 <[hidden email]> wrote:


On Wed, Jul 6, 2016 at 9:37 AM, Wolf Fink <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Michael Musgrove
Transactions Team
t: <a href="tel:%2B44%20191%20243%200870" value="+441912430870" target="_blank">+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)




--
Michael Musgrove
Transactions Team
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)

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev