Configuration, Resource Usage and StdSchedulerFactory

Quartz is architected in modularized way, that's why before running it, several components need to be snapped together. Components  need to be configure before Quartz :

• ThreadPool  - It provides a set of Threads to Quartz and Quartz used these Threads for executing jobs. The more threads available in pool allows the number of jobs can run concurrently. Some Quartz users find that they need 5 threads are enough because they have fewer jobs at any given time, but generally all jobs are not scheduled to execute at the same time and the jobs complete quickly. But some other users find that they need 10,50 and 100 threads because they have some thousands of triggers with various schedule, which can end up by around 10 and 100 jobs trying to execute at any given time. There is no any rule for finding the size of scheduler's pool, it is only depend on what you are using for the scheduler. Too many threads can bog down your system but make sure you have enough threads for executing the jobs.
        
  A ThreadPool interface is defined in the "org.quartz.spi" package. Quartz ships with a simple thread pool named org.quartz.simpl.SimpleThreadPool. It simply maintains a fixed set of threads in its pool that never shrinks and never grows. But it is otherwise quite robust and is very well tested - as nearly everyone using Quartz uses this pool.
      
• JobStore - Job Store are used to keep track of all the "work data" that you give to the scheduler: jobs, triggers, calendars, etc. The important step for Quartz Scheduler step is selecting the appropriate JobStore. You declare which JobStore your scheduler should use (and it's configuration settings) in the properties file (or object) that you provide to the SchedulerFactory that you use to produce your scheduler instance.
       
• DataSource - JDBCJobStore can get the connections to your database by setting up a DataSource. In Quartz properties DataSource can be defined in different approaches. One approach is, Quartz can create and manage the DataSource itself through providing the all connection information to the database. And another approach is, DataSource is used by Quartz which is managed by an application server that Quartz is running inside of - by providing JDBCJobStore the JNDI name of the DataSource.
         
• Scheduler - Finally, you need to create the instance of your Scheduler. Now the Scheduler itself needs to be given a name, told its RMI settings, and handed instances of a JobStore and ThreadPool. The RMI settings include the Scheduler should create itself as an RMI server object, what host and port to use, etc.. StdSchedulerFactory can create Scheduler instances that are actually proxies (RMI stubs) to Schedulers created in remote processes.
       

StdSchedulerFactory

StdSchedulerFactory is a class, that is implementation of org.quartz.SchedulerFactory interface and does all of its work of creating a Quartz Scheduler instance based on the content of properties file. Generally, properties are stored in and loaded from a file, but can also be created by your program and handed directly to the factory. Simply invoking getScheduler() on the factory you get the instance of scheduler.

DirectSchedulerFactory

DirectSchedulerFactory is a class, that is singleton implementation of SchedulerFactory interface. It is useful for those user that want to create their Scheduler instance in more programatic way. Generally, it can be used for the following reasons: (1) it requires the user to have a greater understanding of what they're doing (2) it does not allow for declarative configuration - or in other words, you end up hard-coding all of the scheduler's settings.

Logging

"org.apache.commons.logging" framework is used by Quartz for its logging needs. Quartz does not produce so much logging information, it produce some information during initialization and then messages about serious problems while jobs are executing.