Skip to main content

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

  • From: "mkarg (JIRA)" <jira-no-reply@...>
  • To: issues@...
  • Subject: [ejb-spec issues] [JIRA] Commented: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment
  • Date: Sun, 20 Apr 2014 18:29: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=374610#action_374610
 ] 

mkarg commented on EJB_SPEC-121:
--------------------------------

Reza, don't know what you liked to actually express with your comment on 
"beginners vs kowledgeable folks", as I am using EJB since 1.0 and play the 
role of an Java EE evangelist for more than one decade. I worked together 
with lots of your (former) colleagues of several Java EE sub-specs, becoming 
GlassFish 2.x stable enough for industrial use and those specs clear and 
concise enough for unambiguous understanding, and have contributed to several 
application servers among which are JOnAS and GlassFish. I'm a JAX-RS EG 
member (339, inofficially 311 also), have contributed to the EJB and other 
JSRs. I was a Jersey committer and Oracle TopLink contributor (author of 
SqlAnywhere and MaxDB support now driven by SAP). Just count my JIRA tickets 
and notice the several GAP awards. So let's say, I am everything but NOT a 
beginner w.r.t. Java EE. Be assured I know those discussions, but they all 
miss the point: Programmatically created persistent timers are essential 
business data in fact.

That being said, I need to tell you that I opened this issue on purpose in 
exactly _this_ tracker, because I want to kindly ask *the EJB expert group* 
to discuss the problem outlined in my original posting above: The hypothesis 
that programmatically created persistent timers actually are business data 
hence deleting them has the same severity like deleting database content 
itself, so the EJB specification must specify the behaviour and difference of 
undeploy and redeploy, as it has severe impact on the portability and 
integrity of business applications.

As a side note I want to kindly ask you to not overhastily deal with this 
issue as a "narrow edge case". We are shipping GlassFish application server 
to 1.200+ enterprise world wide and each of them would be very angry to lose 
any single persistent timer by incident when installing an application 
update. Be assured when I tell you that not everything you personally have 
not finally grasped or experienced is non-existent or "narrow edge", even you 
can learn and yes there are people outside of the big vendors who also know 
what they talk about. Please understand that after engineering EJB-driven 
business applications for these companies for more than a decade, "real and 
unlimited" persistency of programmatically created persistent timers are 
actually a CORE feature of EJB for lots of developers. As soon as the 
integrity of this business information is in danger, the whole value of the 
persistent timers facility is totally doubtful. If one needs to create a 
singleton "bootstrap timer rescue" bean, then someone can simply use 
non-persistent timers instead -- by simply using a static frequently firing 
timer looking up application-specific database tables, then producing timer 
events on behalf of the application logic instead -- what implies additional 
burden on the DB, obviously, just as the "timer rescue singleton" does!

Hence, I urge you to get rid of your view that this is a "dummy beginner 
question" and get back into the boat of constructive specification work. This 
issue is about an essential fix of the specification, actually. I hope you 
got it _now_ and let the expert group discuss the facts I told you hereby.


> 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] Created: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

mkarg (JIRA) 04/20/2014

[ejb-spec issues] [JIRA] Commented: (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] Commented: (EJB_SPEC-121) Clarification whether persistent timers have to survive redeployment / undeployment

mkarg (JIRA) 04/20/2014

[ejb-spec issues] [JIRA] Commented: (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
 
 
Close
loading
Please Confirm
Close