Skip to main content

[ejb-spec issues] [JIRA] Issue Comment Edited: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

  • From: "reza_rahman (JIRA)" <jira-no-reply@...>
  • To: issues@...
  • Subject: [ejb-spec issues] [JIRA] Issue Comment Edited: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment
  • Date: Mon, 21 Apr 2014 00:40:49 +0000 (UTC)
  • Auto-submitted: auto-generated


    [ 
https://java.net/jira/browse/EJB_SPEC-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=374612#action_374612
 ] 

reza_rahman edited comment on EJB_SPEC-121 at 4/21/14 12:39 AM:
----------------------------------------------------------------

Frankly I really think you need to calm down a bit and step back from this 
for a period of time. It is rather evident you are taking technical issues 
personally when they are not and making things overly personal when you 
shouldn't be - starting by characterizing a simple technical discussion as a 
"dispute" here or perhaps an even earlier needlessly confrontational outlook 
from the very start.

If this rather old issue warrants further consideration I am sure it will be 
properly followed up upon at some point. This is most certainly not the 
appropriate venue for an ego/emotionally driven tit-for-tat or melodrama (if 
you feel the need to carry out a mostly personal interchange it is always 
fine to email me). Over-the-top personal reactions will most likely undermine 
the possible validity of the technical issue at hand. That's certainly not 
what anyone wants.

Unless you have a further technical detail to share frankly I have little 
more to say on this.

      was (Author: reza_rahman):
    Frankly I really think you need to calm down a bit and step back from 
this for a period of time. It is rather evident you are taking technical 
issues personally when they are not and making things overly personal when 
you shouldn't be - starting by characterizing a simple technical discussion 
as a "dispute" here or perhaps an even earlier needlessly confrontational 
outlook from the very start.

If this rather old issue warrants further consideration I am sure it will be 
properly followed up upon at some point. This is most certainly not the 
appropriate venue for an ego/emotionally driven tit-for-tat (if you feel the 
need to carry out a mostly personal interchange it is always fine to email 
me). Over-the-top personal reactions will most likely undermine the possible 
validity of the technical issue at hand. That's certainly not what anyone 
wants.

Unless you have a further technical detail to share frankly I have little 
more to say on this.
  
> Clarification whether persistent timers have to survive redeployment / 
> undeployment
> -----------------------------------------------------------------------------------
>
>                 Key: EJB_SPEC-121
>                 URL: https://java.net/jira/browse/EJB_SPEC-121
>             Project: ejb-spec
>          Issue Type: Improvement
>    Affects Versions: 3.2
>            Reporter: mkarg
>
> Triggered by a dispute about an unclear section of th EJB 3.2 specification 
> I'd like to suggest that the next maintenance release of the EJB 
> specification provides the following clarification:
>  
> "A persistent timer MUST survive EJB redeployment."
>  
> Optionally I want to suggest that the specification goes further than that 
> an says:
>  
> "A persistent timer MUST survive EJB redeployment and undeployment."
>  
> Justification: Given a long-running business process like subscription 
> management, there are two ways to deal with future business events like 
> automatic subscription extension. The first way is to write the date of 
> next contract extension into a persistent database using JPA, and have a 
> non-persistent timer check this database table daily for any due contracts. 
> This solution survives even undeployment followed by redeployment, as the 
> database content is not touched. The second way is to not write the next 
> contract extension date into the database, but simply set up a persistent 
> timer firing on the day of extension. This offloads the burden of contract 
> book-keeping from the application's code and data tables to the EJB 
> container's persistent timer service. Certainly, an application programmer 
> would expect that when doing a redeployment (or even an undeployment and 
> deployment) will behave exactly the same -- and not kill any timers, as 
> those are not technical instruments but merely valueable business data. If 
> the container would kill that persistent timers at redeployment or 
> undeployment, this business data will get lost, which is clearly not what a 
> developer expects from any persistent technologoy!
>  
> Currently the RI (GlassFish 4.0) by default deletes programatically created 
> persistent timers when a new version of an application is provided by means 
> of redeployment (https://java.net/jira/browse/GLASSFISH-20295). This foils 
> the core idea of both, redeployment (in contrast to undeployment followed 
> by deployment) and persistent timers and threatens the realiability of 
> business applications by behaving in a non-expected way by default.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[ejb-spec issues] [JIRA] Issue Comment Edited: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

(continued)

[ejb-spec issues] [JIRA] Issue Comment Edited: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

reza_rahman (JIRA) 04/20/2014

[ejb-spec issues] [JIRA] Issue Comment Edited: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

reza_rahman (JIRA) 04/20/2014

[ejb-spec issues] [JIRA] Issue Comment Edited: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

reza_rahman (JIRA) 04/20/2014

[ejb-spec issues] [JIRA] Issue Comment Edited: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

reza_rahman (JIRA) 04/20/2014

[ejb-spec issues] [JIRA] Issue Comment Edited: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

reza_rahman (JIRA) 04/20/2014

[ejb-spec issues] [JIRA] Issue Comment Edited: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

reza_rahman (JIRA) 04/20/2014

[ejb-spec issues] [JIRA] Issue Comment Edited: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

reza_rahman (JIRA) 04/20/2014

[ejb-spec issues] [JIRA] Issue Comment Edited: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

reza_rahman (JIRA) 04/20/2014

[ejb-spec issues] [JIRA] Issue Comment Edited: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

reza_rahman (JIRA) 04/20/2014

[ejb-spec issues] [JIRA] Issue Comment Edited: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

reza_rahman (JIRA) 04/20/2014

[ejb-spec issues] [JIRA] Issue Comment Edited: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

reza_rahman (JIRA) 04/21/2014

[ejb-spec issues] [JIRA] Commented: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

mkarg (JIRA) 04/21/2014

[ejb-spec issues] [JIRA] Commented: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

reza_rahman (JIRA) 04/21/2014

[ejb-spec issues] [JIRA] Issue Comment Edited: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

reza_rahman (JIRA) 04/21/2014
 
 
Close
loading
Please Confirm
Close