[cdi-dev] [JBoss JIRA] (CDI-180) Clarify request context lifecycle during remote method invocation of EJB

Mark Struberg (Issue Comment Edited) (JIRA) jira-events at lists.jboss.org
Wed Oct 26 07:47:45 EDT 2011


    [ https://issues.jboss.org/browse/CDI-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637528#comment-12637528 ] 

Mark Struberg edited comment on CDI-180 at 10/26/11 7:46 AM:
-------------------------------------------------------------

I'm not sure if this falls under this category, but do we generally like to define what happens with remote and also with _async_ parts?

E.g. if I have a bean which starts an async EJB task. At first it sounds very tempting to just promote the current RequestContext and SessionContext also over to this async task. But now think a bit about it. The user starts an async EJB method which needs 30 minutes (or even longer) to succeed. Immediately after kicking off the task (long before it finishes), the user logs out and the logOutHandler therefor destroys the Session. What will happen? 
Also please be aware that the methods to programmatically access a Session with a given Id got removed from the Servlet spec long time ago. Plus there are serialization issues.

Back to your original problem (which is different, but the effect is pretty much the same): whenever we cross boundaries (threads, servers), this might work in some situations, but we will fail to support it in a generally valid manner.

                
      was (Author: struberg):
    I'm not sure if this falls under this category, but do we generally like to define what happens with remote and also with _async_ parts?

E.g. if I have a bean which starts an async EJB task. At first it sounds very tempting to just promote the current RequestContext and SessionContext also over to this async task. But now think a bit about it. The user starts an async EJB method which needs 30 minutes (or even longer) to succeed. Immediately after that, the user logs out and the logOutHandler therefor destroys the Session. What will happen? 
Also please be aware that the methods to programmatically access a Session with a given Id got removed from the Servlet spec long time ago. Plus there are serialization issues.

Back to your original problem (which is different, but the effect is pretty much the same): whenever we cross boundaries (threads, servers), this might work in some situations, but we will fail to support it in a generally valid manner.

                  
> Clarify request context lifecycle during remote method invocation of EJB
> ------------------------------------------------------------------------
>
>                 Key: CDI-180
>                 URL: https://issues.jboss.org/browse/CDI-180
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.0
>            Reporter: Martin Kouba
>
> CDI 1.0 spec states in *6.7.1. Request context lifecycle*:
> "The request scope is active: during any remote method invocation of any EJB" and "The request context is destroyed: after the EJB remote method invocation"
> However it doesn't cover various invocation scenarios. For example it's possible to do in-VM invocation (via remote interface) from the same deployment or from a different deployment. Is the request context shared in this case? Will be destroyed after the EJB remote method invocation?
> Also take into account that application servers often do optimization and handle remote interface calls in a local interface manner within the same JVM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the cdi-dev mailing list