wf4中的持久性WorkflowApplication：SQL Server vs ORACLE DevArt

我們有一個24x7的應用程序來處理幾十個WF4實例。wf4中的持久性WorkflowApplication：SQL Server vs ORACLE DevArt

我們使用SQL Instance Store持久化OnIdle成功實施了一個持久保存&恢復策略，在受控關閉中等待該狀態並重新加載恢復。

我們需要移動到ORACLE，我們已經使用DevArt實例存儲和我們有相同的代碼的一些問題。

到目前爲止，我們仍然堅持的OnIdle，但現在我們不得不受控停止以卸載，以便能夠在恢復加載。

我們擔心的來當我們想到可能出現的「不那麼輕輕的」停機。

如果持續執行的實例無法達到受控關閉方法，那麼未卸載的情況如何？如何恢復它們？任何人都面臨同樣的情況？

來源

2012-07-03 The Beat

如何處理Sql服務器的非受控關機？ – Vivek

嗨Vivek，堅持使用自定義監控表的每個On_idle超出WF4持久性可以在系統啓動後重新加載。 –

您是否爲WF持久性提供了WF表以外的其他表？基本思想是「Devart.Data.Oracle.WorkflowFoundation.dll」與使用oracle作爲數據庫的SQL服務器持久性相同。這是一個愚蠢的建議，在實際技術轉移之前，與Devart和oracle進行小型POC。 Devart一個月試用版是免費的。 – Vivek

找到它，

它可以用ORACLE Devart Instance Store完成。問題是OracleInstanceStoreLogic的DevArt dotConnect包中的一個錯誤，它將鎖定過期時間飆升至2037年，不允許再次加載實例。

代替

newLockExpiration：= SYSDATE + p_lockTimeout/24 * 60 * 60;

應該是

newLockExpiration：= SYSDATE + p_lockTimeout /（24 * 60 * 60）;

我已經報告的問題向DevArt傢伙爲了解決它在未來的更新。

來源

2012-07-05 12:54:31

我有一個重要補充的「敲打」了答案：與丟失的括號中的錯誤只拿到固定在一個地方兩個！具體來說，在腳本「OracleInstanceStoreLogic.sql」中有一個方法「ExtendLock」，它仍然有

newLockExpiration：= sysdate + p_lockTimeout/24 * 60 * 60;

（我們在寫作時Devart版本7.8.287.0，而這個錯誤依然存在。）這肯定引起的問題與我們的工作流程，其中又以加括號後離開。

我剛剛向Devart提交了一個錯誤報告。

來源

2013-07-31 08:18:16

希望這個時候它會被固定好。 –

當問題在與dotConnect for Oracle安裝一起提供的「OracleInstanceStoreLogic.sql」中修復時，我們將在此處發佈。 – Devart

新版dotConnect for Oracle 7.9發佈！欲瞭解更多信息，請參閱http://forums.devart.com/viewtopic.php?f=1&t=27875。 – Devart

wf4中的持久性WorkflowApplication：SQL Server vs ORACLE DevArt

回答

相關問題