Jag har en massa olika metodanrop och det i dessa sker en massa databasjox. Om jag vill köra alla dessa i en transaktion, ska jag då skapa denna transaktion innan alla metodanropen och även köra begin transaction, och skriva om metoderna så att de tar transaktionen som parameter?

Nåt sånt här alltså:

<code>
Public Sub DoSomething
Dim oConnection As New OleDbConnection(...)
Dim oTransaction As OleDbTransaction

oConnection.Open()
oTransaction = oConnection.BeginTransaction

Try
my1stObj.Method(param1, param2, oTransaction)
my2ndObj.Method(param3, param4, oTransaction)
my3rdObj.Method(param1, param4, oTransaction)
Catch ex As Exception
oTransaction.Rollback()
Throw New Exception("Fel fel fel!!!", ex)
End Try

oTransaction.Commit()
End Sub
</code>

Jag vill ju att om my3rdObj.Method(...) smäller, så ska det som skedde i my1stObj.Method(...) och my2ndObj.Method(...) göras ogjort.

/M

Jag tycker det ser ok ut. Rätt användning av try-catch för att säkerställa att ändringar rullas tillbaka vid eventuella fel.

/Mattias

Det är så här man är tvungen att göra alltså?

Tja, mer eller mindre. Jag missade tyvärr att du nog måste skicka med connection också eftersom om du tex jobbar med en OledbCommand så måste connection och transaction på dessa båda hänga samman.

Jag skulle nog också fundera på att flytta in oTransaction.Commit in i try-blocket. Det blir tydligare var den hör och ingen risk att man i framtiden hanterar felet i catch-blocket och sedan exekverar Commit trots att det gick fel...

Just eftersom detta lätt kan bli lite krångligt, skicka med connection och transaction hit och dit, så är det ju inte helt ovanligt att använda COM+ för att lösa denna sorts problem. Varje objekt/klass som du anropar skulle i sådana stödja transaktionshantering genom att använda System.EnterpriseServices.ServicedComponent, kolla med på denna klass och namespace för att se vad du kan göra. Vad som sker är att en DTC transaktion startas som sköter hanteringen av transaktionen åt dig, du måste däremot anropa SetComplete eller SetAbort på ContextUtil klassen.

/Mattias

I VB6 skrev jag komponenter en gång i tiden där man angav om transaktioner var Supported, Required, Requires New osv. Hur gör man detta i DotNet? Är det vad du försöker förklara, men som jag uppenbarligen inte kopplar? ;)

Här du ett litet ex på hur du kan skriva en enkel klass som använder Enterprise Services:

<code>
Imports System.Reflection
Imports System
Imports System.EnterpriseServices

<Assembly: ApplicationName("MyServicedComponents")>
<Assembly: AssemblyDescription("This app contains serviced components")>
<Assembly: ApplicationActivation(ActivationOption.Server)>
<Assembly: AssemblyKeyFile("MyKey.snk")>

<Transaction(TransactionOption.Supported)> _
Public Class Account
Inherits System.EnterpriseServices.ServicedComponent

<AutoComplete()> _
Public Sub Debit()
End Sub

<AutoComplete()> _
Public Sub Credit()
End Sub

End Class
</code>

<AutoComplete> kommer att se till så Commit eller RollBack anropas beroende på om allt gick bra eller inte. Om du vill sköta Commiten och Aboirt själv så kan du tabort <AutoComplete()> och använda dig av ContextUtil.SetComplete och ContextUtil.SetAbort.

Du kan använda dig av RegSvcs.exe för att registrera komponenten i Componenet Services eller själv lägga till den i Componentet services. Det går även med lite enkel hack att få komponenten att installera sig själv i Component Services när den körs för första gången. Du hittar allt detta i Framework SDK.

OBS! Tänk på att skapa en nyckel som du signarerar din assemlby med. En nyckel skapar du med "sn -k":

sn -k MyKey.snk

Se även till att skriva in sökvägen till din nyckel i AssemblyKeyFile (Se koden ovan):

<Assembly: AssemblyKeyFile("MyKey.snk")>

Om du inte använder Enterprise services så kan du göra som du gjort i din kod. Transaction objektet har en property .Connection som innehåller den connection som är kopplad till transactionen så du behöver inte skicka med connection till metoderna. Det räcker med transaction objektet.

/Fredrik Normén NSQUARED2
http://www.nsquared2.net