src/docs/configuration.adoc - grails-quartz - Git at Google

 ////
 Licensed to the Apache Software Foundation (ASF) under one
 or more contributor license agreements.  See the NOTICE file
 distributed with this work for additional information
 regarding copyright ownership.  The ASF licenses this file
 to you under the Apache License, Version 2.0 (the
 "License"); you may not use this file except in compliance
 with the License.  You may obtain a copy of the License at

 https://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing,
 software distributed under the License is distributed on an
 "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.
 ////

 [[configuration]]
 == Plugin Configuration


 === Configuring the plugin

 The plugin supports configuration settings defined in grails-app/conf/application.yml.

 [source,yml]
 ----
 quartz:
     autoStartup: true
 ----

 Currently supported options:

 * `autoStartup` Controls automatic startup of the Quartz scheduler during application bootstrap (default: true).
 * `jdbcStore` Set to true if you want Quartz to persist jobs in your DB (default: false). You'll also need to provide a `quartz.properties` file and make sure that required tables exist in your db (see the <<_clustering>> section below for the sample config and automatic tables creation using Hibernate).


 ==== Logging

 A log is auto-injected into your task Job class without having to enable it. To set the logging level, add something like this to your grails-app/conf/Config.groovy log4j configuration.

 [,groovy]
 ----
 debug 'grails.app.jobs'
 ----


 ==== Hibernate Sessions and Jobs

 Jobs are configured by default to have Hibernate Session bounded to thread each time a job is executed. This is required if you are using Hibernate, which requires open session (such as lazy loading of collections) or working with domain objects with unique persistent constraint (it uses Hibernate Session behind the scene). If you want to override this behavior (rarely useful) you can use `sessionRequired` property:

 [,groovy]
 ----
 static sessionRequired = false
 ----


 ==== Configuring concurrent execution

 By default, jobs are executed in concurrent fashion, so new job execution can start even if the previous execution of the same job is still running. If you want to override this behavior, you can use `concurrent` property. In this case Quartz's `StatefulJob` will be used (you can find more info about it here).

 [,groovy]
 ----
 static concurrent = false
 ----


 ==== Configuring Job Enabled

 By default, all jobs are considered enabled. In some cases it may be desired to temporarily disable a job. This can be done by overriding the `jobEnabled` property behavior.

 [,groovy]
 ----
 static jobEnabled = false
 ----


 ==== Configuring description

 Quartz allows for each job to have a short description. This may be configured by adding a description field to your Job. The description can be accessed at runtime using the `JobManagerService` and inspecting the `JobDetail` object.

 [,groovy]
 ----
 static description = 'Example Job Description'
 ----


 [#_clustering]
 ==== Clustering

 Quartz plugin doesn't support clustering out-of-the-box now. However, you could use a standard Quartz clustering configuration. You'll also need to set `jdbcStore` configuration option to `true`.

 There are also two parameters for configuring store/clustering on jobs, volatility and durability (both are true by default) and one for triggers, volatility (also true by default). A volatile job and trigger will not persist between Quartz runs, and a durable job will live even when there are no triggers referring to it.

 Read Quartz documentation for more information on clustering and job stores as well as volatility and durability.

 Now that the plugin supports Quartz `2.1.x`, you can use current versions of open source Terracotta see https://github.com/rvanderwerf/terracotta-grails-demo for an example app.


 ==== Recovering

 Since `0.4.2` recovering from a 'recovery' or 'fail-over' situation is supported with the `requestsRecovery` job-level flag (false by default).

 If a job "requests recovery", and it is executing during a 'hard shutdown' of the scheduler, (i.e., the process it is running within crashes, or the machine is shut off), then it is re-executed when the scheduler is started again. In this case, the `JobExecutionContext.isRecovering()` method will return `true`.
	////
	Licensed to the Apache Software Foundation (ASF) under one
	or more contributor license agreements. See the NOTICE file
	distributed with this work for additional information
	regarding copyright ownership. The ASF licenses this file
	to you under the Apache License, Version 2.0 (the
	"License"); you may not use this file except in compliance
	with the License. You may obtain a copy of the License at

	https://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing,
	software distributed under the License is distributed on an
	"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
	KIND, either express or implied. See the License for the
	specific language governing permissions and limitations
	under the License.
	////

	[[configuration]]
	== Plugin Configuration


	=== Configuring the plugin

	The plugin supports configuration settings defined in grails-app/conf/application.yml.

	[source,yml]
	----
	quartz:
	autoStartup: true
	----

	Currently supported options:

	* `autoStartup` Controls automatic startup of the Quartz scheduler during application bootstrap (default: true).
	* `jdbcStore` Set to true if you want Quartz to persist jobs in your DB (default: false). You'll also need to provide a `quartz.properties` file and make sure that required tables exist in your db (see the <<_clustering>> section below for the sample config and automatic tables creation using Hibernate).


	==== Logging

	A log is auto-injected into your task Job class without having to enable it. To set the logging level, add something like this to your grails-app/conf/Config.groovy log4j configuration.

	[,groovy]
	----
	debug 'grails.app.jobs'
	----


	==== Hibernate Sessions and Jobs

	Jobs are configured by default to have Hibernate Session bounded to thread each time a job is executed. This is required if you are using Hibernate, which requires open session (such as lazy loading of collections) or working with domain objects with unique persistent constraint (it uses Hibernate Session behind the scene). If you want to override this behavior (rarely useful) you can use `sessionRequired` property:

	[,groovy]
	----
	static sessionRequired = false
	----


	==== Configuring concurrent execution

	By default, jobs are executed in concurrent fashion, so new job execution can start even if the previous execution of the same job is still running. If you want to override this behavior, you can use `concurrent` property. In this case Quartz's `StatefulJob` will be used (you can find more info about it here).

	[,groovy]
	----
	static concurrent = false
	----


	==== Configuring Job Enabled

	By default, all jobs are considered enabled. In some cases it may be desired to temporarily disable a job. This can be done by overriding the `jobEnabled` property behavior.

	[,groovy]
	----
	static jobEnabled = false
	----


	==== Configuring description

	Quartz allows for each job to have a short description. This may be configured by adding a description field to your Job. The description can be accessed at runtime using the `JobManagerService` and inspecting the `JobDetail` object.

	[,groovy]
	----
	static description = 'Example Job Description'
	----


	[#_clustering]
	==== Clustering

	Quartz plugin doesn't support clustering out-of-the-box now. However, you could use a standard Quartz clustering configuration. You'll also need to set `jdbcStore` configuration option to `true`.

	There are also two parameters for configuring store/clustering on jobs, volatility and durability (both are true by default) and one for triggers, volatility (also true by default). A volatile job and trigger will not persist between Quartz runs, and a durable job will live even when there are no triggers referring to it.

	Read Quartz documentation for more information on clustering and job stores as well as volatility and durability.

	Now that the plugin supports Quartz `2.1.x`, you can use current versions of open source Terracotta see https://github.com/rvanderwerf/terracotta-grails-demo for an example app.


	==== Recovering

	Since `0.4.2` recovering from a 'recovery' or 'fail-over' situation is supported with the `requestsRecovery` job-level flag (false by default).

	If a job "requests recovery", and it is executing during a 'hard shutdown' of the scheduler, (i.e., the process it is running within crashes, or the machine is shut off), then it is re-executed when the scheduler is started again. In this case, the `JobExecutionContext.isRecovering()` method will return `true`.