[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
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 /
> 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:
For more information on JIRA, see: http://www.atlassian.com/software/jira