Source

quartz / docs / features.html

<html>
<head>
	<title>Quartz - Features</title>
</head>

<body>


<h3>Runtime Environments</h3>
<ul>
	<li>Quartz can run embedded within another free standing application</li>
	<li>Quartz can be instantiated within an application server (or servlet container),
		and participate in XA transactions</li>
	<li>Quartz can run as a stand-alone program (within its own Java Virtual Machine),
		to be used via RMI</li>
	<li>Quartz can be instantiated as a cluster of stand-alone programs (with load-balance
		and fail-over capabilities)</li>
</ul>


<h3>Job Scheduling</h3>
<p>Jobs are scheduled to run when a given Trigger occurs. Triggers can be created
with nearly any combination of the following directives:
<ul>
	<li>at a certain time of day (to the millisecond)</li>
	<li>on certain days of the week</li>
	<li>on certain days of the month</li>
	<li>on certain days of the year</li>
	<li>not on certain days listed within a registered Calendar (such as business holidays)</li>
	<li>repeated a specific number of times</li>
	<li>repeated until a specific time/date</li>
	<li>repeated indefinitely</li>
	<li>repeated with a delay interval</li>
</ul>
Jobs are given names by their creator and can also be organized into named groups.
Triggers may also be given names and placed into groups, in order to easily organize them
within the scheduler. Jobs can be added to the scheduler once, but registered with multiple
Triggers. Within a J2EE environment, Jobs can perform their work as part of a distributed
(XA) transaction.
</p>

<h3>Job Execution</h3>
<ul>
	<li>Jobs can be any Java class that implements the simple Job interface, leaving infinite
		possibilities for the work your Jobs can perform.</li>

	<li>When a Trigger occurs, the scheduler notifies zero or more Java objects implementing
		the JobListener and TriggerListener interfaces (listeners can be simple Java objects,
		or EJBs, or JMS publishers, etc.). These listeners are also notified after the Job
		has executed.</li>

	<li>As Jobs are completed, they return a JobCompletionCode which informs the scheduler of
		success or failure. The JobCompletionCode can also instruct the scheduler of any actions
		it should take based on the success/fail code - such as immediate re-execution of the Job. </li>
</ul>


<h3>Job Persistence</h3>
<ul>
	<li>The design of Quartz includes a JobStore interface that can be implemented to provide
	    various mechanisms for the storage of jobs.</li>
	<li>With the use of the included JDBCJobStore, all Jobs and Triggers configured as
	    "non-volatile" are stored in a relational database via JDBC.</li>
	<li>With the use of the included RAMJobStore, all Jobs and Triggers are stored in
	    RAM and therefore do not persist between program executions - but this has the
	    advantage of not requiring an external database.</li>
</ul>

<h3>Transactions</h3>
<ul>
	<li>Quartz can participate in JTA transactions, via the use of JobStoreCMT (a subclas of JDBCJobStore).</li>
	<li>Quartz can manage JTA transactions (begin and commit them) around the execution of a Job, so that the work the Job does happens within a JTA transaction.</li>
</ul>

<h3>Clustering</h3>
<ul>
	<li>Fail-over.</li>
	<li>Load balancing.</li>
</ul>

</body>
</html>