Adding a bullet about cancelling all non-persistent timers is fine.
Florent
On 07/12/2012 01:43 AM, Marina Vatkina wrote:
> Thanks.
>
> Do you see a problem with adding a bullet about cancelling all
> non-persistent timers?
>
> -marina
>
> Florent BENOIT wrote:
>> +1 Option B without the last bullet
>>
>> Florent
>>
>> On 07/11/2012 03:06 AM, Marina Vatkina wrote:
>>> Experts,
>>>
>>> I'm not making any changes in this area until I hear your opinions...
>>>
>>> -marina
>>>
>>> Marina Vatkina wrote:
>>>> 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>
>>>>>>>>>
>>>>>>>>> ]
>>>>>>>>> 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> | Twitter
>>>>>>>>> <http://twitter.com/agoncal> | Blog
>>>>>>>>> <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn
>>>>>>>>> <http://www.linkedin.com/in/agoncal> | Paris JUG
>>>>>>>>> <http://www.parisjug.org>
>>>>>>>>>
>>>>>>>>> No virus found in this message.
>>>>>>>>> Checked by AVG - www.avg.com <http://www.avg.com>
>>>>>>>>> Version: 2012.0.2171 / Virus Database: 2437/5079 - Release
>>>>>>>>> Date:
>>>>>>>>> 06/19/12
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>