Affects Version/s: 3.2
Fix Version/s: None
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.