that makes good sense. There is an open issue on this - https://issues.apache.org/jira/browse/AMQ-5238
On Sat, 26 Sep 2015 at 13:30 Erik Wramner <e...@wramner.name> wrote: > I'm considering implementing a JDBC job scheduler store. The current > state of affairs where there is only a memory and KahaDB job scheduler > store means that it is impossible to use JDBC as a highly available > backend with scheduled messages, including messages scheduled by the > redelivery plugin. However, in my view the job scheduler store interface > is deeply flawed. > > The problem is that the store does nothing. It can get or set a > directory (useless with JDBC), it can return the number of jobs > scheduled (OK) and it can return or remove job schedulers. The job > schedulers do all the heavy lifting. > > This works, but it means that every time a new persistence mechanism is > added we must implement the scheduler again. I really don't want to > implement a job scheduler just to save jobs to a database instead of to > the file system (with KahaDB). I think it would be much better if we > could refactor the JobSchedulerStore interface to provide the > persistence operations that are used by the two existing schedulers. > That way it would be much easier to write a JDBC scheduler store and a > LevelDB scheduler store and a new-exciting-storage-not-yet-available > scheduler store without reinventing the wheel (the basic scheduling) > every time. > > What do you think? > > -Erik >
