Beständighetsdeltagare
En beständig deltagare kan delta i en beständighetsåtgärd (Spara eller Läs in) som utlöses av en programvärd. .NET Framework 4.6.1 levereras med två abstrakta klasser, PersistenceParticipant och PersistenceIOParticipant, som du kan använda för att skapa en beständig deltagare. En beständig deltagare härleds från en av dessa klasser, implementerar intressanta metoder och lägger sedan till en instans av klassen i WorkflowExtensions samlingen på WorkflowServiceHost . Programvärden kan söka efter sådana arbetsflödestillägg när en arbetsflödesinstans bevaras och anropa lämpliga metoder för beständighetsdeltagarna vid lämpliga tidpunkter.
I följande lista beskrivs de uppgifter som utförs av persistence-undersystemet i olika faser av åtgärden Persist (Spara). Beständighetsdeltagarna används i den tredje och fjärde etappen. Om deltagaren är en I/O-deltagare (en beständig deltagare som också deltar i I/O-åtgärder) används deltagaren också i det sjätte steget.
Samlar in inbyggda värden, inklusive arbetsflödestillstånd, bokmärken, mappade variabler och tidsstämpel.
Samlar in alla beständighetsdeltagare som har lagts till i tilläggssamlingen som är associerad med arbetsflödesinstansen.
Anropar metoden som CollectValues implementeras av alla beständighetsdeltagare.
Anropar metoden som MapValues implementeras av alla beständighetsdeltagare.
Spara eller spara arbetsflödet i beständighetsarkivet.
Anropar BeginOnSave metoden för alla I/O-deltagare med beständighet. Om deltagaren inte är en I/O-deltagare hoppas den här uppgiften över. Om beständighetsavsnittet är transaktionellt anges transaktionen i egenskapen Transaction.Current.
Väntar på att alla beständiga deltagare ska slutföras. Om alla deltagare lyckas bevara instansdata genomför du transaktionen.
En beständig deltagare kommer från klassen PersistenceParticipant och kan implementera metoderna CollectValues och MapValues . En beständig I/O-deltagare härleds från klassen PersistenceIOParticipant och kan implementera metoden BeginOnSave förutom att implementera metoderna CollectValues och MapValues .
Varje fas slutförs innan nästa steg börjar. Till exempel samlas värden in från alla beständighetsdeltagare i den första fasen. Sedan tillhandahålls alla värden som samlas in i den första fasen till alla beständighetsdeltagare i den andra fasen för mappning. Sedan tillhandahålls alla värden som samlas in och mappas i de första och andra stegen till beständighetsprovidern i den tredje fasen och så vidare.
I följande lista beskrivs de uppgifter som utförs av beständighetsundersystemet i olika steg i belastningsåtgärden. Beständighetsdeltagarna används i den fjärde etappen. Beständighets-I/O-deltagare (beständighetsdeltagare som också deltar i I/O-åtgärder) används också i den tredje fasen.
Samlar in alla beständighetsdeltagare som har lagts till i tilläggssamlingen som är associerad med arbetsflödesinstansen.
Läser in arbetsflödet från beständighetsarkivet.
Anropar BeginOnLoad I/O-deltagare för all beständighet och väntar på att alla beständighetsdeltagare ska slutföras. Om beständighetsavsnittet är transaktionellt anges transaktionen i Transaction.Current.
Läser in arbetsflödesinstansen i minnet baserat på de data som hämtats från beständighetslagret.
Anropar PublishValues för varje beständig deltagare.
En beständig deltagare kommer från klassen PersistenceParticipant och kan implementera metoden PublishValues . En beständig I/O-deltagare härleds från klassen PersistenceIOParticipant och kan implementera metoden BeginOnLoad förutom att implementera metoden PublishValues .
När du läser in en arbetsflödesinstans skapar beständighetsprovidern ett lås på den instansen. Detta förhindrar att instansen läses in av mer än en värd i ett scenario med flera noder. Om du försöker läsa in en arbetsflödesinstans som har låsts visas ett undantag som följande: Undantaget " System.ServiceModel.Persistence.InstanceLockException: Den begärda åtgärden kunde inte slutföras eftersom låset för instansen "00000000-0000-0000-0000-000000000" inte kunde förvärvas". Det här felet orsakas när något av följande inträffar:
I ett scenario med flera noder läses instansen in av en annan värd. Det finns några olika sätt att lösa dessa typer av konflikter: vidarebefordra bearbetningen till noden som äger låset och försök igen, eller tvinga den belastning som gör att den andra värden inte kan spara sitt arbete.
I ett scenario med en nod kraschade värden. När värden startar igen (en process återanvänder eller skapar en ny leverantörsfabrik för beständighet) försöker den nya värden läsa in en instans som fortfarande är låst av den gamla värden eftersom låset inte har upphört att gälla ännu.
I ett scenario med en nod och den aktuella instansen avbröts någon gång och en ny instans av beständighetsprovidern skapas som har ett annat värd-ID.
Tidsgränsvärdet för låset har ett standardvärde på 5 minuter. Du kan ange ett annat timeout-värde när du anropar Load.
