2012-07-03 1 views
0

Nous avons une application 24x7 qui traite des douzaines d'instances WF4.Persistance dans wf4 WorkflowApplication: SQL Server vs ORACLE DevArt

Nous avons implémenté avec succès une stratégie de récupération de persistance & à l'aide d'OnIdle persistante de stockage d'instance SQL, en attendant ce statut dans l'arrêt contrôlé et le chargement dans la récupération.

Nous devions passer à ORACLE et nous avons utilisé DevArt Instance Store et nous avons quelques problèmes avec le même code. Jusqu'ici, nous continuons à utiliser OnIdle, mais maintenant nous avons dû décharger à l'arrêt contrôlé afin de pouvoir charger dans la récupération. Notre peur vient quand nous pensons aux fermetures «pas si doucement» qui peuvent apparaître.

Qu'en est-il des instances persistantes sans être déchargées si elles ne peuvent pas atteindre la méthode d'arrêt contrôlé? Comment les récupérer? Quelqu'un a-t-il fait face à la même situation?

+0

Comment vous gérez un arrêt non contrôlé avec le serveur Sql? – Vivek

+0

Hi Vivek, persistant dans chaque On_idle utilisant des tables de surveillance personnalisées à partir de la persistance WF4 peut être rechargé à nouveau une fois le système démarré. –

+0

Avez-vous ajouté vos propres tables en dehors des tables WF fournies pour la persistance WF? L'idée de base est "Devart.Data.Oracle.WorkflowFoundation.dll" fonctionne aussi bien que la persistance du serveur SQL en utilisant Oracle comme base de données. C'est une suggestion stupide qui fait un petit POC avec Devart et oracle avant le changement de technologie réel. Devart un mois d'essai est gratuit. – Vivek

Répondre

2

Je l'ai trouvé,

Il peut être fait avec ORACLE Devart instance Store. Le problème était un bogue dans le paquet DevArt dotConnect de OracleInstanceStoreLogic qui a propulsé le temps d'expiration de verrouillage jusqu'à 2037 interdisant de charger à nouveau l'instance.

Au lieu de

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

devrait être

newLockExpiration: = sysdate + p_lockTimeout/(24 * 60 * 60);

J'ai déjà signalé le problème aux développeurs DevArt afin de le corriger lors de la prochaine mise à jour.

2

J'ai un ajout important à la réponse de "The Beat": l'erreur avec les parenthèses manquantes a seulement fixé à un endroit de deux! Plus précisément, il existe une méthode "ExtendLock" dans le script "OracleInstanceStoreLogic.sql" qui a toujours

newLockExpiration: = sysdate + p_lockTimeout/24 * 60 * 60; (Nous avons la version Devart 7.8.287.0 au moment de l'écriture, et le bug est toujours là). Cela a définitivement causé des problèmes avec nos workflows qui ont disparu après l'ajout des parenthèses.

Je viens de déposer un rapport de bogue sur Devart.

+0

Espérons que cette fois, il sera définitivement réparé. –

+0

Nous publierons ici lorsque le problème est résolu dans "OracleInstanceStoreLogic.sql" fourni avec l'installation de dotConnect pour Oracle. – Devart

+1

Nouvelle version de dotConnect pour Oracle 7.9 est disponible! Pour plus d'informations, veuillez vous référer à http://forums.devart.com/viewtopic.php?f=1&t=27875. – Devart