Jeremy,
Jeremy Bauer wrote:
> Marina,
>
> Initially, it seemed like a good idea to add more predictability to
> the embeddable container, but that could result in inconsistencies
> with the server environment. OptionB more-so than Option A.
>
> Option A seems reasonable, though. In addition to asynch method
> invocations, it could apply to non-persistent timers as well.
OK. I can add that.
> I don't think one would expect a asynch invocation to run or a pending
> timer to fire after the container has been closed. Regarding the
> behavior of in-flight asynchronous invocations, my vote would be to
> mark the behavior as undefined.
I'd rather not spell out an undefined behavior...
-marina
> This allows vendors the ability to maintain behavior in embeddable
> and server modes and provides more flexibility in their
> threading/thread management mechanism.
>
> -Jeremy
>
>
>
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
> To: jsr345-experts_at_ejb-spec.java.net,
> Date: 07/06/2012 01:25 PM
> Subject: [jsr345-experts] Re: EJB_SPEC-57) Define asynchronous
> thread behavior upon close of embeddable container]
> ------------------------------------------------------------------------
>
>
>
> I can change the last sentence in the 1st par in this section to be
> either:
>
> Option A:
> During the processing of the close() method, the embeddable container
> must cancel all pending asynchronous invocations and call the PreDestroy
> methods of any singleton session bean instances in the application.
>
> or
>
> Option B:
> During the processing of the close() method, the embeddable container
> performs the following steps:
> * cancels all pending asynchronous invocations
> * calls the PreDestroy methods of any singleton session bean
> instances in the application
> * aborts execution of bean methods that are still active
>
>
> My concern with the last bullet in the option (B) (or adding something
> similar to (A)) is that it's not clear that PreDestroy methods will be
> allowed to complete.
>
> Let me know what you prefer.
>
> -marina
>
> Florent BENOIT wrote:
> > I think that now that async is supported for Embeddable container we
> > should add the change on the section.
> >
> >
> > Florent
> >
> >
> > On 07/05/2012 10:50 PM, Marina Vatkina wrote:
> >> Experts,
> >>
> >> I'm not making any changes to the section "18.2.4Embeddable Container
> >> Shutdown" unless I hear otherwise.
> >>
> >> -marina
> >>
> >> Marina Vatkina wrote:
> >>> Does the spec need to say this explicitly?
> >>>
> >>> thanks,
> >>> -marina
> >>>
> >>> Jean-Louis MONTEIRO wrote:
> >>>> +1
> >>>>
> >>>>
> >>>> 2012/6/19 Reza Rahman <reza_rahman_at_lycos.com
> >>>> <mailto:reza_rahman_at_lycos.com>>
> >>>>
> >>>> +1
> >>>>
> >>>>
> >>>> On 6/19/2012 12:07 PM, Antonio Goncalves wrote:
> >>>>> Well, would expect the same behavior you discribe for GlassFish
> >>>>> : the execution is aborted when the server shutsdown (I don't
> >>>>> want the embedded container to get locked while a thread is
> >>>>> trying to finish its processing).
> >>>>>
> >>>>> Antonio
> >>>>>
> >>>>> On Fri, Jun 15, 2012 at 11:38 PM, Marina Vatkina
> >>>>> <marina.vatkina_at_oracle.com <mailto:marina.vatkina_at_oracle.com>>
> wrote:
> >>>>>
> >>>>> Experts,
> >>>>>
> >>>>> What do your think? How do you expect your embedded
> >>>>> containers handle the async calls during EJBContainer.close
> >>>>> and JVM exit?
> >>>>>
> >>>>> GlassFish (RI) uses the same code for embedded and regular
> >>>>> shutdown, where the bean is unloaded right away, and any
> >>>>> method execution is pretty much aborted when the server
> >>>>> shutdown event is received. JVM exit is intercepted and
> >>>>> EJBContainer.close() steps are executed in the background.
> >>>>>
> >>>>> thanks,
> >>>>> -marina
> >>>>>
> >>>>> -------- Original Message --------
> >>>>> Subject: [ejb-spec issues] [JIRA] Commented:
> >>>>> (EJB_SPEC-57) Define asynchronous thread behavior upon close
> >>>>> of embeddable container
> >>>>> Date: Thu, 14 Jun 2012 14:39:55 +0000 (GMT+00:00)
> >>>>> From: jrbauer (JIRA) <jira-no-reply_at_java.net
> >>>>> <mailto:jira-no-reply_at_java.net>>
> >>>>> Reply-To: issues_at_ejb-spec.java.net
> >>>>> <mailto:issues_at_ejb-spec.java.net>
> >>>>> To: issues_at_ejb-spec.java.net
> >>>>> <mailto:issues_at_ejb-spec.java.net>
> >>>>>
> >>>>>
> >>>>>
> >>>>> [
> >>>>>
> >>>>>
> http://java.net/jira/browse/EJB_SPEC-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341464#action_341464
> <http://java.net/jira/browse/EJB_SPEC-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341464#action_341464>
>
> >>>>>
> >>>>>
> <http://java.net/jira/browse/EJB_SPEC-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341464#action_341464
> <http://java.net/jira/browse/EJB_SPEC-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341464#action_341464>>
>
> >>>>>
> >>>>> ]
> >>>>> jrbauer commented on EJB_SPEC-57:
> >>>>> ---------------------------------
> >>>>>
> >>>>> Section 18.2.4 (pd1) does contain some verbiage around
> >>>>> shutdown requirements and expectations of the embeddable
> >>>>> container. I shied away mentioning any sort of asynch
> >>>>> shutdown expectations for containers in an EE environment
> >>>>> since I too couldn't find anything around this topic in the
> >>>>> specs. Introducing something now would likely cause
> >>>>> compatibility issues for most vendors. But, since asynch
> >>>>> support will be new in the embeddable container we have an
> >>>>> opportunity to introduce some commonality/predictability
> >>>>> without release compatibility concerns.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Define asynchronous thread behavior upon close of
> >>>>> embeddable container
> >>>>>
> >>>>>
> ----------------------------------------------------------------------
> >>>>>
> >>>>>
> >>>>> Key: EJB_SPEC-57
> >>>>> URL:
> >>>>> http://java.net/jira/browse/EJB_SPEC-57
> >>>>> Project: ejb-spec
> >>>>> Issue Type: Improvement
> >>>>> Affects Versions: 3.2
> >>>>> Reporter: jrbauer
> >>>>>
> >>>>> Issue EJB_SPEC-13 adds asynchronous method invocation to
> >>>>> EJB lite, which may be implemented by an embeddable
> >>>>> container. The specification should define the behavior
> >>>>> of the embeddable container regarding any outstanding
> >>>>> asynchronous invocations upon closing the container
> >>>>> (EJBContainer.close()) and since close() is not
> required,
> >>>>> exit of main within the JVM.
> >>>>> Transactionally, it seems to make the most sense for
> >>>>> EJBContainer.close() and JVM exit to wait for any
> >>>>> outstanding asynchronous threads before exiting. This
> >>>>> provides consistent behavior, but at the risk of having
> >>>>> an ill-behaved thread block the container or JVM from
> >>>>> closing/exiting.
> >>>>>
> >>>>>
> >>>>> -- This message is automatically generated by JIRA.
> >>>>> -
> >>>>> If you think it was sent incorrectly contact one of the
> >>>>> administrators:
> >>>>> http://java.net/jira/secure/Administrators.jspa
> >>>>> -
> >>>>> For more information on JIRA, see:
> >>>>> http://www.atlassian.com/software/jira
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> -- Antonio Goncalves
> >>>>> Software architect and Java Champion
> >>>>>
> >>>>> Web site <http://www.antoniogoncalves.org
> <http://www.antoniogoncalves.org/>> | Twitter
> >>>>> <http://twitter.com/agoncal> | Blog
> >>>>> <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn
> >>>>> <http://www.linkedin.com/in/agoncal> | Paris JUG
> >>>>> <http://www.parisjug.org <http://www.parisjug.org/>>
> >>>>>
> >>>>> No virus found in this message.
> >>>>> Checked by AVG - www.avg.com <http://www.avg.com
> <http://www.avg.com/>>
> >>>>> Version: 2012.0.2171 / Virus Database: 2437/5079 - Release Date:
> >>>>> 06/19/12
> >>>>>
> >>>>
> >>>>
> >
>
>