These properties configure the identification of the scheduler and other top level settings.

Can be any string, and the value has no meaning to the scheduler itself - but rather serves as a mechanism for client code to distinguish schedulers when multiple instances are used within the same program. If you are using the clustering features, you must use the same name for every instance in the cluster that is 'logically' the same Scheduler.

Can be any string, but must be unique for all schedulers working as if they are the same 'logical' Scheduler within a cluster. You may use the value "AUTO" as the instanceId if you wish the Id to be generated for you. Or the value "SYS_PROP" if you want the value to come from the system property org.quartz.scheduler.instanceId.

Only used if org.quartz.scheduler.instanceId is set to AUTO. Defaults to "org.quartz.simpl.SimpleInstanceIdGenerator," which generates an instance id based upon host name and time stamp. Other IntanceIdGenerator implementations include SystemPropertyInstanceIdGenerator (which gets the instance id from the system property org.quartz.scheduler.instanceId), and HostnameInstanceIdGenerator, which uses the local host name (InetAddress.getLocalHost().getHostName()). You can also implement the InstanceIdGenerator interface your self.

Any String that is a valid name for a Java thread. If this property is not specified, the thread will receive the scheduler's name (org.quartz.scheduler.instanceName) plus an the appended string "_QuartzSchedulerThread".

A Boolean value (true or false) that specifies whether the main thread of the scheduler should be a daemon thread or not. See also the org.quartz.threadPool.makeThreadsDaemons property for tuning the SimpleThreadPool in ThreadPool Configuration if that is the thread pool implementation you are using (which is usually the case).

A Boolean value (true or false) that specifies whether the threads spawned by Quartz will inherit the context ClassLoader of the initializing thread (i.e., the thread that initializes the Quartz instance). This will affect Quartz main scheduling thread, JDBCJobStore’s misfire handling thread (if JDBCJobStore is used), cluster recovery thread (if clustering is used), and threads in SimpleThreadPool (if SimpleThreadPool is used). Setting this value to true may help with class loading, JNDI look-ups, and other issues related to using Quartz within an application server.

The amount of time in milliseconds that the scheduler will wait before it re-queries for available triggers when the scheduler is otherwise idle. You should normally not have to adjust this parameter unless you're using XA transactions and are having problems with delayed firings of triggers that should fire immediately. Values less than 5000 ms are not recommended as it will cause excessive database querying. Values less than 1000 are not valid.

The amount of time in milliseconds that the scheduler will wait between re-tries after it detects a loss of connectivity within the JobStore (i.e., to the database). This parameter is not meaningful when using RamJobStore.

Defaults to the most robust approach, which is to use the org.quartz.simpl.CascadingClassLoadHelper class, which in turn uses every other ClassLoadHelper class until one works. In general, you should not need to use any other class for this property. However, it might be useful for resolving class-loading issues on application servers. All of the current possible ClassLoadHelper implementations can be found in the org.quartz.simpl package.

The class name of the JobFactory to use. A JobFatcory is responsible for producing instances of JobClasses. The default is org.quartz.simpl.PropertySettingJobFactory, which simply calls newInstance() on the class to produce a new instance each time execution is about to occur. PropertySettingJobFactory also reflectively sets the job's bean properties using the contents of the SchedulerContext and Job and Trigger JobDataMaps.

A name-value pair that will be placed into the scheduler context as strings (see Scheduler.getContext()). For example, setting the org.quartz.context.key.MyKey to "MyValue" would perform the equivalent of scheduler.getContext().put("MyKey", "MyValue").

The JNDI URL at which Quartz can locate the application server’s UserTransaction manager. The default value (if not specified) is "java:comp/UserTransaction." which works for almost all application servers. WebSphere users may need to set this property to "jta/usertransaction". This is only used if Quartz is configured to use JobStoreCMT, and org.quartz.scheduler.wrapJobExecutionInUserTransaction is set to true.

Set to true if you want Quartz to start a UserTransaction before calling execute on your job. The Tx will commit after the job's execute method completes, and after the JobDataMap is updated (if it is a StatefulJob). The default value is false. You may also be interested in using the @ExecuteInJTATransaction annotation on your job class, which lets you control for an individual job whether Quartz should start a JTA transaction. The wrapJobExecutionInUserTransaction property causes it to occur for all jobs.

Whether or not to skip running a quick web request to determine if there is an updated version of Quartz available for download. If the check runs, and an update is found, it will be reported as available in the Quartz logs. You can also disable the update check with the system property org.terracotta.quartz.skipUpdateCheck=true (which you can set in your system environment or as a -D on the Java command line). It is recommended that you disable the update check for production deployments.

The maximum number of triggers that a scheduler node is allowed to acquire (for firing) at once. Default value is 1. The larger the number, the more efficient firing is (in situations where there are very many triggers needing to be fired all at once), but at the cost of possible imbalanced load between cluster nodes. If the value of this property is > 1, and JDBC JobStore is used, then the property org.quartz.jobStore.acquireTriggersWithinLock must be set to true to avoid data corruption.

The amount of time (in milliseconds) that a trigger is allowed to be acquired and fired ahead of its scheduled fire time. Defaults to 0. The larger the number, the more likely batch acquisition of triggers to fire will be able to select and fire more than one trigger at a time. However, this comes at the cost of the trigger schedule not being honored precisely (triggers might fire early). This property can be useful (for the sake of performance) in situations where the scheduler has a very large number of triggers that need to be fired at or near the same time.