Persistent Timers

Liberty persistent timers are configured by default to support the Cúram timer infrastructure.

For more information about Cúram timer infrastructure, see the Social Program Management Server Developer’s Guide.

This configuration takes advantage of the Liberty capability, provided by release 20.0.0.1, to share a set of timer database tables across Liberty servers, which in our case run in Kubernetes pods.

Sharing database timer tables avoids the issue where automatic creation of timer tables that occurs at each and every server/pod start could pose a database limit risk. Consider a typical SPM deployment of Curam, Rest, CitizenPortal, and Web Service applications with consumer and producer pods and three replicas. On initial start that deployment would create 72 database tables. It’s not hard to imagine the many hundreds or thousands of tables that could be created over time as replicas are scaled up, pods restarted, and so forth.

The sharing of timer tables immediately reduces the number of timer tables required to a much more manageable number and, more importantly, keeps the number of tables bounded. This is achieved by grouping deployments into pod types. For instance, one set of timer tables for all apps-curam-producer pods (one pod type), similarly for all apps-curam-consumer pods (another pod type), for all apps-rest-producer pods (another pod type), and so forth. Thus, based on one set of tables per pod type the above example deployment requiring 72 tables is now fixed at 24 tables, regardless of how many replicas are started. The pod type is derived at deployment time and exposed as an environment variable, which is read by the Liberty configuration: ${env.POD_TIMER_TYPE}.

The out-of-the-box configuration of Liberty persistent timers should be adequate for most use cases. However, Helm Chart overrides are available for the most relevant Liberty settings that can be used to adjust behavior or performance depending upon your application, environment, etc. For more information see the Configuration Reference and the WebSphere Liberty documentation.

If you are migrating to SPM V8 you may cleanup the obsolete timer tables in your database. To do this you need to be aware of how the timer tables were named previously.
Being created uniquely for each pod means that the tables were named based on the pod name. That is, the table names included the replicaset unique identifier (UUID), which is no longer used. For example, a pod named release-apps-curam-producer-76c8464b4d-9tzlx would have mapped to a table name of EJBTIMER_RELEASE_APPS_CURAM_CONSUMER_76C8464B4D_9TZLX_PART, which now maps to EJBTIMER_RELEASE_APPS_CURAM_CONSUMER_PART, etc.

Since the old naming is no longer used those timer tables are obsolete once you migrate to SPM V8 and the tables can safefly be removed. In cleaning up obsolete tables you need to be careful to only identify obsolete tables. The following SQL will generate DROP DDL statements that map specifically to the old table naming:

Before executing the DROP statements ensure that none of the pods identified by the table names are running.