jsr345-experts@ejb-spec.java.net

[jsr345-experts] Re: EJB_SPEC-57) Define asynchronous thread behavior upon close of embeddable container]

From: Reza Rahman <reza_rahman_at_lycos.com>
Date: Tue, 19 Jun 2012 12:55:37 -0400

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