Currently Quartz only has CamelJob which implements Quartz's Job interface. There is no option to use an implemenation of StatefulJob. This causes problems when you may want to use a JDBC JobStore and have Quartz running on multiple machines, as you may end up with multiple jobs running together. StatefulJob in effect allows for a blocking singleton style job on one machine.
Attached is a patch which adds a new URI parameter named "stateful", which defaults to false. When set to true it uses StatefulCamelJob.
One significant change to the QuartzComponent is that a reference to the CamelContext is now stored in the Quartz Scheduler. This idea is taken from Spring's SchedulerFactoryBean which stores a reference to a Spring ApplicationContext. This is needed as when using stateful jobs the URI of the Endpoint is stored instead of a reference to the endpoint. This is to allow for the use of JDBC JobStore as the URI can be serialised and shared beteen participating schedulers.
Still has no notion of volatility
Difference in operation between CamelJob and StatefulCamelJob is not strictly needed. It may be less confusing if both versions simply store the URI instead of an endpoint reference.
You need to use stateful if you want to use clustering at all due to the reason above. This is mixing together clustering support and blocking functionality.
In Camel 2 we may want to try rewriting this Component as it is becoming a little messy. It would be nice to try and harness the power of Spring's SchedulerFactoryBean.