Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
I normal drift skulle en programkomponent som körs i en serverprogramprocess använda en COM+ CRM genom att skapa en CRM-arbetare. CRM-arbetaren implementerar ett COM-gränssnitt som är specifikt för den uppgift som den är utformad för att utföra. Programkomponenten måste köras under en transaktion så att CRM-arbetaren ärver transaktionen för programkomponenten. CRM-arbetare kräver alltid en transaktion.
För att få åtkomst till COM+ CRM hämtar CRM-arbetaren först ICrmLogControl--gränssnittet, vilket gör att CRM-arbetaren kan skriva poster till den beständiga loggen. CRM-arbetaren hämtar det här gränssnittet genom att skapa en CRM-kontoristkomponent.
Därefter måste CRM-arbetaren tala om CRM-kontoristen namnet på CRM-kompenseraren den vill använda. Det gör det genom att anropa metoden ICrmLogControl::RegisterCompensator. När den här metoden har anropats skapas CRM-kompenseraren av CRM-infrastrukturen när transaktionen slutförs.
När CRM-arbetaren har registrerat sin CRM-kompenserare kan den skriva poster till CRM-loggen med hjälp av ICrmLogControl-. CRM-arbetaren måste skriva i förväg; det vill säga, den måste skriva en post till loggen som beskriver en åtgärd innan den faktiskt utför åtgärden, i fall en krasch inträffar omedelbart efter att åtgärden har slutförts. Utan dessa loggposter för framåtskrivning finns det inget sätt att korrigera för åtgärden.
Förskrivning innebär också att CRM-kompenseraren, som är den komponent som tar emot loggposterna vid återställning, måste hantera situationen där loggposterna skrevs men åtgärden faktiskt inte inträffade. Åtgärder från CRM-kompenseraren måste vara idempotent; De bör alltså kunna utföras mer än en gång, men bör leda till samma resultat. Till exempel är det en idempotent åtgärd att ange ett kontosaldo till värdet $100. att lägga till 100 USD i kontosaldot är inte det.
Gränssnittet ICrmLogControl innehåller följande två metoder för att skriva loggposter:
- WriteLogRecordVariants används för att skriva en strukturerad loggpost som har byggts upp som en samling varianter. Det är främst för användning när du utvecklar CRM:er i Microsoft Visual Basic.
- WriteLogRecord används för att skriva en ostrukturerad loggpost som BLOBs av bytes. Det är främst för användning när du utvecklar CRM:er i Microsoft Visual C++. Eftersom poststrukturer i C ofta består av en uppsättning rubriker och fält som kan vara utspridda i minnet, implementerar metoden WriteLogRecord en insamlingsfunktion som minskar kopieringen av data.
Notera
Du bör inte använda pekartyper i datastrukturer i en loggpost. Pekare är inte längre giltiga under återställningsfasen eftersom CRM-kompenseraren körs i en annan process än den CRM-arbetare som skrev loggposten. Om du inkluderar pekartyper i en loggpost kan ett program krascha eller skada sig själv under återställningen.
Båda dessa skrivmetoder skriver en loggpost till disken men garanterar inte postens hållbarhet. Om du tillåter att fördröjda skrivningar ackumuleras innan du tvingar dem till disk kan du förbättra prestandan, men du kan använda metoden ICrmLogControl::ForceLog istället för att garantera att alla skrivningar som görs av CRM-systemet är hållbara på disken, vilket är viktigt för återställning efter fel.
När CRM-arbetaren är klar med sitt arbete och har skrivit och tvingat in poster till loggen måste den släppa ICrmLogControl. När transaktionen slutförs (vanligtvis på grund av att programkomponenten anropar SetComplete eller SetAbort) skapar CRM-infrastrukturen CRM-komponenten Compensator, som implementerar antingen ICrmCompensator--gränssnittet eller ICrmCompensatorVariants-gränssnittet. Dessa gränssnitt används för att skicka ostrukturerade (Visual C++) eller strukturerade (Visual Basic) poster till CRM-kompenseraren tillsammans med meddelanden om transaktionsresultat.
CRM-kompensationsgivaren meddelas först om förberedelsefasen för transaktionens slutförande och kan rösta ja eller nej till förberedelsebegäran. Om CRM-kompensatorn röstar nej, får den inga ytterligare avbrottsnotiser. Om den röstar ja till att förberedelsebegäran godkänns får den antingen av commit- eller avbryt-meddelanden. Vid ett klientavbrott tas inga förberedelsemeddelanden emot, endast avbrottsmeddelanden. CRM-kompenseraren måste vara förberedd att hantera alla dessa fall, och den måste dessutom hantera det fall där inga loggposter har skrivits framgångsrikt av CRM-arbetaren. Det CRM-kompenserare får inte förutsätta att samma CRM-kompenserare instans tar emot både aviseringarna fas 1 (förbereda) och fas 2 (genomför eller avbryter), eftersom dessa kan avbrytas av återställning.
En CRM-kompenserare använder vanligtvis ett avbrottsmeddelande för att ångra den specifika åtgärd som initierats av CRM-arbetaren. CRM-medarbetaren kan lämna viss information tillgänglig om den behöver återkalla sin åtgärd. Det tillståndet kan vara helt inneslutet i loggposterna, och om inte måste CRM-kompensatorn städa upp det tillståndet om transaktionen går igenom. Det är anledningen till att CRM-kompenseraren tar emot incheckningsmeddelandet. CRM-kompenseraren körs inte i en transaktion med DTC.
CRM-kompensatorn kan logga nya poster om det krävs med hjälp av ICrmLogControl, vilket den får tillgång till när den skapas. Både CRM-arbetaren och CRM-kompenseraren kan också glömma den sista loggposten som de skrev, vilket kan krävas för att undvika onödig återställning.
Relaterade ämnen