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 <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