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 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
>