Currently I have one monolith application whereby I have created many EJB timers programatically to expire sometime on the future. I use Java EE 7 and WildFly 12 to do it. I have configured WildFLy to persist it onto a database which then it gets serialized and saved ready to be handled on its TimeOut, all working fine here. Now I am splitting the monolith onto microservices and facing the issue of migrating those timers.
Is there any way of doing it in a clean way? Any suggestions are welcome.
Firstly I tried to update the timers on the database and notice that won't work as the objects are serialized with added metadata which contains the deployment war file it belongs to.
Secondly I was thinking on creating a one off batch to loop through every timer and publish a message if the timer is to be removed so the new microservice will receive that message and create the timer on its own schema with the right deployment information. However I dont like this solution as it is very messy and involves adding lots of if statements to cater for different type of timers.
ejb_timer_id = warFileName.warFileName.MyTimerEventHandler
expire_date = 2019-01-04 08:55:00.0000000
serialized_object = Pk9jb20ubWlkbGFuZGhyLnRyZW50LnRhbGVudC5jaGVja2luLnRpbWVycy5OZXh0U2NoZWR1bGVkQ2hlY2tJbkV4cGlyZWRUaW1lckV2ZW50GHMausCwvz8+FGRlcGxveW1lbnQudHJlbnQud2FyPgRtYWluAAAAAj4YbmV4dFNjaA==
To make it work, I need to successfully update the ejb_timer_id from warFileName.warFileName.MyTimerEventHandler to newWarFileName.newWarFileName.MyTimerEventHandler and the serialized object will need to be update to contain the new deploymnet details eg from myWarFile to myNewWarFile
The timers are not meant to have a migration between different applications or beans. So this is a manual process. Also there could be side affects if an application is undeployed/redeployed and the timer beans has changed or removed. It is possible that the timer data is still in the persistence.