Clarification whether persistent timers have to survive redeployment / undeployment

[glassfishrobot]

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.

Affected Versions

[3.2]

[glassfishrobot]

Reported by mkarg

[glassfishrobot]

reza_rahman said: For further context, it is useful to explore fairly common discussions such as these (often initiated by EJB/Java EE beginners and responded to by more knowledgeable folks/vendors): http://stackoverflow.com/questions/7930420/jee6-timer-persistence-across-redeploy. As both a user and an implementer it has always been clear to me personally why an implementation will likely choose to completely remove all application state related to the application upon undeploy/redeploy in order to reliably maintain consistency in a properly regimented production environment. In fact, this is what all major implementations that I know of do today and GlassFish is one of the few implementations that I know of that allows persistent timers to be kept across redeployment by allowing it to be an explicit user option overriding default behavior.

That all being said, it may (or may not) be worth further clarifying this fairly minor (and relatively well understood) issue in the spec. On the other hand, this is likely to cause undue backwards compatibility issues for implementations to support a narrow edge case.

[glassfishrobot]

mkarg said: 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.

[glassfishrobot]

reza_rahman said: 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.

[glassfishrobot]

mkarg said: 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.

[glassfishrobot]

reza_rahman said: It's good this rather unsavory matter has come to a timely end and also that you've freely admitted your apparent emotionally/personally rooted rather than technically driven motivations (that I must say is a total mystery to me). Just so you are aware, any Oracle employee is free (and in fact encouraged) to share their informed opinions on any JCP technology openly at any time - particularly folks working in the Java EE team like me. Indeed that is true of any interested Java developer. If you have a problem with that I would say that is rather unfortunate, telling and contrary to the open spirit of the JCP.

Just to be clear, the current behavior is indeed based on past EG consensus and something both Marina and Ken have been long aware of.

[glassfishrobot]

This issue was imported from java.net JIRA EJB_SPEC-121