A példány zárolt kivételművelete

Az InstanceLockedExceptionAction SQL Workflow Instance Store tulajdonságával megadhatja, hogy milyen műveletet kell elvégeznie az SQL-adatmegőrzési szolgáltatónak, amikor kap egy InstanceLockedException. Az adatmegőrzési szolgáltató akkor kapja meg ezt a kivételt, ha egy másik szolgáltatásgazda által jelenleg zárolt munkafolyamat-szolgáltatáspéldányt próbál zárolni. Ennek a tulajdonságnak az értékei a következőkNoRetry: és BasicRetryAggressiveRetry. Az alapértelmezett érték a NoRetry. Az alábbi lista a három lehetőséget ismerteti:

  • NoRetry. A szolgáltatás gazdagépe nem próbálja zárolni a munkafolyamat-szolgáltatáspéldányt, és átadja a InstanceLockedException hívónak. Ha a munkafolyamat 60 másodpercnél hosszabb ideig marad a memóriában, próbálkozzon NoRetry újra. Az alapértelmezett érték a NoRetry.

  • BasicRetry. A szolgáltatásgazda újra megkísérli zárolni a munkafolyamat-szolgáltatáspéldányt az újrapróbálkozási kísérletek közötti lineáris intervallummal, és átadja a InstanceLockedException hívónak a sorozat végén. Ha a munkafolyamat körülbelül 5–60 másodperc között marad a memóriában, és az üzenetek olyan kötegekben érkeznek, amelyekben nagyobb a valószínűsége annak, hogy ugyanazon a gazdagépen ugyanarra a példányra küldött üzenetek feldolgozzák az összes üzenetet a munkafolyamat eltávolítása előtt, a BasicRetry lehető legjobb késés elérése erőforrások nélkül.

  • AggressiveRetry. A szolgáltatásgazda újra megkísérli zárolni a munkafolyamat-szolgáltatáspéldányt az újrapróbálkozási kísérletek közötti exponenciális visszalépési időközzel, és átadja a kivételt a hívónak a sorozat végén. Ha a munkafolyamat nagyon rövid ideig (kevesebb, mint 5 másodpercig) marad a memóriában, vagy egy webfarm nagy méretű, és nem túl nagy az esélye annak, hogy egy másik üzenet érkezik ugyanahhoz a gazdagéphez, használja AggressiveRetry a legjobb késést.

A Példány zárolt kivételművelet funkció a következő forgatókönyveket támogatja. Minden esetben, ha az SqlWorkflowInstanceStore BasicRetryAggressiveRetryinstanceLockedExceptionAction tulajdonsága az vagy, a gazdagép transzparensen újrapróbálkozott a példányok zárolásának rendszeres beszerzéséhez.

  1. Az alkalmazástartományok kecses leállításának és átfedésben lévő újrahasznosításának engedélyezése. Tegyük fel, hogy a munkafolyamat-szolgáltatáspéldányokat futtató szolgáltatás-gazdagéppel rendelkező AppDomain újraindul, és egy új AppDomaint hoz létre az új kérések párhuzamos kezeléséhez, miközben a régi AppDomain elegánsan le van állítva. A leállítás megvárja, amíg a munkafolyamat-szolgáltatáspéldányok tétlenek lesznek, majd megőrzi és eltávolítja a példányokat. Ha az új AppDomain gazdagépei megpróbálnak zárolni egy példányt InstanceLockedException, az egy .

  2. A tartós munkafolyamatok horizontális skálázása egy homogén kiszolgálófarmban. Tegyük fel, hogy egy kiszolgálófarm csomópontja, amelyen egy munkafolyamat-példány fut, összeomlik, és a munkafolyamat-gazdagép nem tudja eltávolítani a futtatott példány zárolásait. Amikor a farm egy másik csomópontján futó szolgáltatás-gazdagép kap egy üzenetet a munkafolyamat-példányhoz, megpróbál zárolásokat szerezni ezeken a példányokon, a rendszer megkapja a InstanceLockedException. A zárolások egy idő után lejárnak, mert a zárolás megújítására szánt gazdagép már nem létezik.

    A tartós munkafolyamatok horizontális skálázása egy homogén kiszolgálófarmban. Tegyük fel, hogy egy tartós munkafolyamatot horizontálisan szeretne horizontálisan skálázni egy hálózati terheléselosztó (Hálózati terheléselosztó) mögött több gazdagép használatával, a farm egyik csomópontján futó munkafolyamat-gazdagép betölt egy munkafolyamat-példányt, és feldolgoz egy üzenetet, a következő üzenet pedig a másik csomóponton futó gazdagépre lesz irányítva, mert a hálózati terheléselosztó nem rendelkezik útválasztási algoritmussal az üzenetek továbbításához a példányt már futtató gazdagépnek. Az üzenet fogadása után a második gazdagép megpróbálja betölteni a munkafolyamat-példányt, és megkapja azt, InstanceLockedException mert az első gazdagép zárolva van a példányon. Az első gazdagép feloldja a példány zárolását, amikor az első üzenet feldolgozásával befejeződött, a második gazdagép pedig a következő alkalommal újrapróbálkozáskor szerzi be a zárolást, betölti a példányt, és feldolgozza a második üzenetet.