[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: Mon, 21 Apr 2014 07:47:49 +0000 (UTC)
- Auto-submitted: auto-generated
mkarg commented on EJB_SPEC-121:
Reza, to end this unwanted and senseless discussion I'd like to also be
frankly: I didn't take the technical issue personally. I can live with the
fact how it is designed, as long as it is discussed and decided by the expert
group. What made me outrage is your particular way to talk to me, nothing
else. Until the expert group discusses it, and unless you are elected as the
the new EJB spec lead, I do not see any sense in posting your personal
opinion into _this_ tracker, hence, to further discuss with you. In fact, my
posting was solely a reaction to _that_. Having that said, I also have
nothing more to add.
> 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