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