Announcement

**Andreas Kosch** · 03.04.2003, 06:46

Hallo,

>Wie schaff ich das?

der Entwickler muss an dieser Stelle nicht eingreifen, dass macht COM+ automatisch. Wenn bei einem SetAbort-Aufruf der Datensatz nicht implizit �ber ein ROLLBACK widerrufen wird, ist es das Beste, den Profiler des MS SQL Server auf die Lauer zu legen, um die Ursache f�r dieses Problem einzukreisen (siehe Abbildung 9.15 auf Seite 448).

Parallel dazu kann man im MMC-Snapin f�r die Komponentendienste im Zweig Districuted Transaction Coordinator die Seite Transaktionsstatistik aufrufen. Dort wird jeder SetComplete-/SetAbort-Aufruf mitgez�hlt. Erh�ht sich dort die Anzeige in der Spalte Abgebrochen, wenn das eigene COM+ Objekt die Methode SetAbort aufruft

**Daniel Auth** · 03.04.2003, 11:08

Hallo,

ein Rollback �ber SetAbort funktioniert. Allerdings nur fuer die zuletzt benutzte Transaktion. Der DS der ein SetAbort provoziert wird also durch ein Rollback zurueckgenommen. Ich m�chte aber, dass auch der vorherige, mit SetComplete abgeschlosssene, DS zurueckgenommen wird. Die Insert Anweisung (bzw. die Stored Procedure) fuer diesen DS l�uft aber in einer eigenen Transaktion die nach dem SetComplete ja abgeschlossen ist. 
 
Ich denke, dass ich fuer die L�sung noch eine "uebergeordnete" Transaktion ben�tige. In etwa sollen die Transaktionen wie folgt ablaufen: 
 
Start Transaktion 1 
Start Transaktion 1 1 
INSERT DS 1 
Ende Transaktion 1 1 durch Commit 
 
Start Transaktion 1 2 
INSERT DS 2 
Ende Transaktion 1 2 durch Rollback 
Ende Transaktion 1 durch Rollback 
 
d.h. es darf auch nicht mehr der zuerst eingefuegte DS 1 in der DB stehen (Atomicity Eigenschaft!) 
 
Wie schaffe ich es das der MTS die "�bergeordnete" Transaktion 1 erstellt? 
Daniel Auth 
 
PS: der Profiler des MS Sql Servers zeigt immer nur einen Nested Level von 1 an

**Andreas Kosch** · 04.04.2003, 06:26

Hallo,

>Wie schaffe ich es das der MTS die "�bergeordnete" Transaktion 1 erstellt?

f�r diesen Einsatzfall unterscheidet der MTS bzw. COM+ zwischen den Transaktions-Attributen Neu erforderlich und Erforderlich (siehe Eigenschaftsdialog | Registerseite Transaktionen). Der Entwickler kann sich zwischen 2 Alternativen entscheiden:

1. Alternative: MTS/COM+ Objekt beh�lt zwischen den beiden Aufrufen f�r das Einf�gen von DS1 und DS2 den Zustand: 
a) Client ruft die Interface-Methode auf, um den DS1 einzuf�gen 
b) MTS/COM+ Objekt ruft EnableCommit auf, um die Transaktion offen zu halten 
c) Client ruft die Interface-Methode auf, um den DS2 im Kontext der gleichen Transaktion einzuf�gen 
d) MTS/COM+ Objekt ruft SetAbort auf, um beide Datens�tze (DS1+DS2) �ber einen Rollback zur�ckzunehmen

2. Alternative: Zwei MTS/COM+-Objekte mit unterschiedlicher Konfiguration: 
a) Das erste MTS/COM+-Objekt mit der Transaktions-Einstellung Neu erforderlich legt den DS 1 im Kontext einer neuen Transaktion an 
b) Das zweite MTS/COM+-Objekt mit der Transaktions-Einstellung Erforderlich legt DS2 an, wobei es automatisch beim Aufruf aus dem 1. Objekt heraus im bereits bestehenden Transaktionskontext ausgef�hrt wird 
c) Das erste MTS/COM+-Objekt ruft SetAbort auf - beide Datens�tze werden �ber ROLLBACK zur�ckgenommen.

>..einen Nested Level von 1 an.

Der Abschnitt 9.6 in meinem Buch betrachtet den Sonderfall, dass eine deklarative COM+ Transaktion die innerhalb einer Stored Procedure aufgerufene T-SQL-Transaktion "�berstimmt". Generell gilt, dass die COM+ Transaktion das Gesamtverhalten bestimmt. Daher ist es normal, wenn der Profiler immer nur den maximalen Wert von 1 anzeigt.

P.S: In T-SQL w�rde eine verschachtelte Transaktion so aussehen:
<pre>

BEGIN TRAN TestMainTransaction
...
SAVE TRAN TestBookmark1
...
ROLLBACK TRAN TestBookmark1
...
COMMIT TRAN

</pre>

Announcement

Nested Transactions

Nested Transactions

Comment

Comment

Comment