[email protected] wrote >> My thinking at the moment is that the following bits would need to be >> done: >> * make the default broker@enableScheduler=true use the current mechanism, >> with the behaviour as-is >> * create a new configuration node under >> broker/schedulerPersistenceAdapter, >> which if defined would override the default persistence settings; this >> could >> be used to plug in a jdbcSchedulerPersistenceAdapter, and optionally a >> kahaDBSchedulerPersistenceAdapter (the existing one - I understand that >> is a >> customized version of KahaDB) - this could have a nice side effect that >> things like the scheduler data directory could be configurable. > Optimally I think it would be nice if the scheduler store could be > obtained from a query of the currently configured persistent store and > then perhaps fall back to the default KahaDB scheduler if that library > is on the class path. This would allow the configuration of the > scheduler store to ride along with the persistence adapter.
Thanks Tim, I was thinking the same thing, since I can't really see why someone would necessarily want to split JDBC/KahaDB on purpose - but changing the default behaviour could be a surprise to users doing an upgrade, especially if they had unconsumed messages in the KahaDB scheduler store when a new version switches to JDBC. The other side of this is that we would end up with mKahaDB and LevelDB without an equivalent scheduler store. Would KahaDB be a fallback if no JobSchedulerStore was found in the persistence adapter in use? Jakub -- View this message in context: http://activemq.2283324.n4.nabble.com/AMQ-3024-Scheduler-should-support-non-Kaha-persistence-tp4669599p4669608.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
