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