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>
Reply-To: issues_at_ejb-spec.java.net
To: 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 ]
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