第九課 JobStores

           JobStore是負責跟蹤排程器中所有的工作資料：作業任務、觸發器、日曆等。為你的Quartz排程器例項選擇一個適當的JobStore是非常重要的一步。幸運的是，一旦你理解了這些JobStore之間的區別，選擇它們是非常容易的事。你可以在配置檔案（或是類物件）中定義排程器使用哪種JobStore，這個JobStore將會提供給SchedulerFactory，用來建立你的排程器例項。

        不要在你的程式碼中直接使用JobStore例項，因為一些原因許多開發者嘗試這樣做。JobStore是給Quartz在幕後使用的。你只需要通過配置資訊告知Quartz

RAMJobStore

         RAMJobStore是最容易使用的JobStore，它也是最高效的（從CPU時間計算）。從RAMJobStore的名字可以明顯地發現：它將所有資料儲存在RAM中。這就是為什麼它速度快並且配置簡單的原因。缺點是當你的應用終止（或是崩潰）時，所有的排程資訊都會丟失——這意味著RAMJobStore會導致作業任務和觸發器的non-volatility設定不起作用。對某些應用來說，這種缺點可以接受，甚至需要這樣的特性，但對另外一些應用來說，這種缺點可能會成為一個災難。

       假定你正在使用StdSchedulerFactory

       Quartz配置檔案中使用RAMJobStore

org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore

       這裡再沒有別的設定需要你去操心了。

JDBCJobStore

         JDBCJobStore同樣人如其名——它通過JDBC將所有的資料儲存在資料庫中。正因為如此配置JDBCJobStore要比RAMJobStore

         JDBCJobStore幾乎可以適用於任何資料庫，它已經在Oracle,PostgreSQL, MySQL, MS SQLServer, HSQLDB和 DB2資料庫中廣泛使用。為了使用JDBCJobStore，你必須先建立一套資料庫表供Quartz使用。你可以在Quartz釋出包的“docs/dbTables”目錄找到建表SQL指令碼。如果現成的指令碼不適合你的資料庫型別，找到其中一個指令碼，想盡一切必要的方法修改成適合你的資料庫。需要注意一點是在這些指令碼中，所有表的字首都是“QRTZ_”（例如表“QRTZ_TRIGGERS”和“QRTZ_JOB_DETAIL”）。這個字首實際上可以是任何你想要的。只要你告訴JDBCJobStore字首是什麼（在Quartz配置檔案裡）。使用不同的字首可能用來在同一個資料庫中建立多套資料表，供多個排程器例項使用。

        一旦你建立了資料表，在配置和觸發JDBCJobStore之前你需要作多個重要決定。你需要決定你的應用需要什麼型別的事務。如果你不需要把排程命令（例如新增和移除觸發器）和其他事務捆綁在一起，那麼你就讓Quartz使用JobStoreTx作為JobStore管理事務（這個是最常用的選擇）。

        如果你需要Quartz關聯其他事務（例如在J2EE應用伺服器中），然後你應該使用JobStoreCMT——這種情況下Quartz會讓應用服務容器管理事務。

       最後一件難題是從JDBCJobStore中設定DataSource，用來獲得資料庫的連線。資料來源在Quartz配置中定義，從幾種不同方式中選擇其中一種。一種方式是Quartz自己建立和管理資料來源——通過提供所有的資料庫連線資訊。另一種方式是Quartz使用由Quartz執行所在的應用伺服器中的資料來源——將資料來源的JNDI名字提供給JDBCJobStore。想了解更多引數的詳細資訊，請查閱“docs/config”資料夾的示例配置檔案。

       假定你正在使用StdSchedulerFactory，想要使用JDBCJobStore時，只需要在Quartz配置檔案中將JobStore class引數的值指定為org.quartz.impl.jdbcjobstore.JobStoreTX或org.quartz.impl.jdbcjobstore.JobStoreCMT的類全名即可——你可以根據上面幾段文字中的解釋決定你的選擇。

       Quartz配置檔案中使用JobStoreTx

org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX

       接下來，你需要選擇DriverDelegate給JobStore使用。DriverDelegate負責完成任何JDBC的工作，它需要和指定的資料庫型別對應。StdJDBCDelegate是使用“vanilla”JDBC程式碼和SQL語句完成工作的一種delegate。如果沒有專門與你的資料庫對應的delegate，嘗試使用這個delegate——我們只是為資料庫開發對應的delegates，並且已經發現使用StdJDBCDelegate的問題（好像是問題最多的）。其他的delegates可以在org.quartz.impl.jdbcjobstore包或子包中找到。其他的delegates包括DB2v6Delegate(DB2 6及更早版本), HSQLDBDelegate (HSQLDB資料庫), MSSQLDelegate(微軟SQLServer資料庫),PostgreSQLDelegate (PostgreSQL資料庫), WeblogicDelegate (使用Weblogic 的JDBC的資料庫), OracleDelegate(Oracle資料庫)和其他。

       一旦你選擇了delegates，設定delegate的類全名給JDBCJobStore使用。

       使用DriverDelegate配置JDBCJobStore

org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate

       接下來，你需要通知JobStore你使用的表字首（前面討論過）配置JDBCJobStore的表字首

org.quartz.jobStore.tablePrefix = QRTZ_

       最後，你需要設定JobStore使用哪個資料來源。資料來源的名字也必須在Quartz配置中定義。既然這樣，我們指定Quartz的資料來源的名字為“myDS”（即在配置檔案另外的引數中定義）。

    配置JDBCJobStore的資料來源名字：

org.quartz.jobStore.dataSource = myDS

       如果排程器繁忙（例如幾乎總是執行跟執行緒池一樣多的作業任務），你可能需要設定資料來源的連線數，大約比執行緒池數多2個。

org.quartz.jobStore.useProperties配置引數可以設定為“true”（預設為false），為了通知JDBCJobStore所有在JobDataMaps的值都會為String型別，因此可以作為鍵值對儲存，而不是在BLOB列中儲存序列化的物件。這從長遠看來更安全，例如你可以避免將非String類物件序列化到BLOB中導致的類版本問題。

TerracottaJobStore

         TerracottaJobStorer提供了一種不需要使用資料的可伸縮，健壯的方案。這意味著資料庫在Quartz方面可以保持空載，而是將所有的資源儲存在應用的其他部分中。

         TerracottaJobStore可以在叢集或非叢集環境中執行，在任何一種環境下，應用伺服器重啟期間都提供一個永久儲存job資料的介質，因為這些資料儲存在Terracotta伺服器中。這個比通過JDBCJobStore使用資料庫的方式高效（大約高一個數量級），但比RAMJobStore慢。

       假定你正在使用StdSchedulerFactory，想要使用TerracottaJobStore時，只需要在Quartz配置檔案中將類名JobStore class引數的值指定為org.quartz.jobStore.class= org.terracotta.quartz.TerracottaJobStore，並且額外加一行配置指定Terracotta伺服器地址。

    使用Terracotta配置Quartz

org.quartz.jobStore.class = org.terracotta.quartz.TerracottaJobStore
org.quartz.jobStore.tcConfigUrl = localhost:9510