Hi Marina,
IMO, the container should not interrupt the PreDestroy method invocation so
I guess the last bullet is confusing (at least for me).
Jean-Louis
2012/7/11 Marina Vatkina <marina.vatkina_at_oracle.com>
> 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<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 <issues_at_ejb-spec.java.net>>
>>>>>>> To: issues_at_ejb-spec.java.net
>>>>>>> <mailto:issues_at_ejb-spec.java.**net <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 <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<http://java.net/jira/secure/Administrators.jspa>
>>>>>>> -
>>>>>>> For more information on JIRA, see:
>>>>>>> http://www.atlassian.com/**software/jira<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<http://feeds.feedburner.com/AntonioGoncalves>>
>>>>>>> | LinkedIn
>>>>>>> <http://www.linkedin.com/in/**agoncal<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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>