Any guidance on axon-trader showcasing scheduled events in Mongo with quartz scheduler. Haven’t connected the dots on how to do that?
Thanks and Cheers
Do you mean using a MongoDB instance to store quartz schedules? If that's
the case: I'm not planning anything in that area for now.
Cheers,
Allard
Thats a challenge for implementation as now we have to maintian a mysql( any RDMS) instance for quartz along with NOSQL … so any help guidance to solve for that should go a long way for the implementor of an Axon app wanting to leverage axons brilliant scheduled event feature, which is a key feature for a business app to send time based messages based on state of an Aggregate. Any thoughts or help for this…
and your thoughts on tracking this feature for noSQL to make that subsystem fully compatible as the SQL subsystem.
Thanks and Cheers…
R
Hi…
So, another option is that if we stick to mySQL for all persistence, cluster it… use caching for repository(query layer(update listners write to db and cache which is clustered), all reads come from cache or db and leverage distributed bus for multjvm webapp, we could attain full scale out with distributed bus for multinode footprint relatively quickly with all upcoming almost complete feature.
This could help with OLTP data integrity, speed and resilience.
FYI… played with ehcache integration with annotations on repository interfaces and it is fairly trivial hookup.
Any thoughts?
Cheers…
The problem is: I can't provide implementations for things in all
frameworks that can possibly be related to Axon. A MongoDB based storage
for Quartz is just a whole different ball game. Quartz has the interfaces
for it, so it should be possible. It's just not a thing I can permit myself
to put the focus on at this point in time.
I am not quite following the thought process on this....
I understand .. The point I was trying to elaborate on is to leverage consistent infrastructure for all dimensions of the framework in multi node environment, a MySQL(or other jpa persistence) cluster with tomcat(web server) cluster could give full feature leverage and maturity with current version 2.0 scope and mature integrations including the scheduling integration with quartz.
For more speed an integrated cache like ehcache could help improve performance of query db for that topology as a thought.
Hope that clarifies.
Thx... And cheers...
I see the point now. In some circumstances, a consistent structure can help. Mostly in applications with relatively small througput. Having a single datastore for all components will definitely help. I have done one of my projects this way, and it works pretty well.
However, some other applications will not benefit from such archtecture. When dealing with massive throughput, you will usually pick a different datastore for each component. Mongo is very suitable as an event store, but may not be the best solution as a querydb.
Using a cache on the command model will enhance throughput. A cache on the query model will generally not bring you much. In fact, the whole idea of the query model is that you can denormalize it to simplify (and thus speed up) query execution.
The whole idea of CQRS is that you should apply it in an architecture that is tailored to the specific needs of each project. That's the fun of it! (especially when it comes to implementing Axon to support al possible uses...)
Cheers,
Allard
You’d have to provide custom implementation of org.quartz.spi.JobStore and configure the scheduler instance to use it (for example via quartz.properties file with org.quartz.jobStore.class key). Unfortunately, the JobStore interface is quite large (~50 methods to implement) so it might take a while.
Actually I think that might be a good exercise to refresh my knowledge of Quartz and learn some more about MongoDB… Thanks for the idea 
W dniu czwartek, 26 kwietnia 2012 08:15:16 UTC+2 użytkownik coderinabstract napisał:
Hi all,
looks like somebody already did the work for us: https://github.com/mulesoft/quartz-mongodb/blob/master/src/main/java/com/mulesoft/quartz/mongo/MongoDBJobStore.java
This one looks a bit more complete (containing tests, to begin with): https://github.com/michaelklishin/quartz-mongodb
Cheers,
Allard
PS. If I ever put an interface with 44 methods in Axon, will somebody please slap me in my face? 
Sorry if I haven’t put enough study time into this… If I use one of these libs that you found (at my own risk of course), do I only have to configure Quartz or is there something required from Axon that you need to implement first?
No worries…
There is absolutely no Axon configuration involved. Other than just using the Quartz scheduler, of course.Note that Axon 1.3 uses quartz 1.x. Axon 1.4 (and 2) will depend on quartz 2. I don’t know if the JobStore implementations I linked to are based on 1 or 2. Or maybe there is no difference…
Cheers,
Allard
Has anybody used this Quartz implementation for mongo? Any experiences?
Thanks and Cheers…