Rollback efter commit

Du kan kun lave rollback hvis du har bedt om at få tingene kørt i en transacton, og du kan ikke lave rollback efter at du har committed.

Fat i transaktionsloggen? Mig bekendt kan man ikke på nogen måde pille ved loggen, eller bruge den til noget fornuftigt. Det er noget MSSQL styrer.

Kan det virkeligt være rigtigt? Det er fordi jeg skal lave noget transaktionsstyring på et højere niveau sådan så selve transaktionen til databasen egentlig bare er en af de ting der skal udføres i den samlede transaktion. I givet fald vil det kræve at jeg selv gemmer ændringerne og laver nogle rollbackrutiner - hvilket efter min mening godt kan være besværligt at gøre robust.

Ja, men det er MSSQL jo kold overfor :o)

Du har en fin transaktonsstyring i MSSQL, men hvis din application skal lave det over flere trin, så vil du sikkert være nødt til at committe flere gange, og så er løbet kørt.

Ok, så er der ikke andet for end at kode sig ud af et rollback. Virker egentlig underligt at funktionaliteten til rollback er der men man lukker helt for muligheden efter commit. Havde ellers været nyttigt til mange ting...

Nå men smid et svar så får du nogen points...

Det er jo lidt fidusen med Commit. Idet du committer tillader du at den tilhørende log bliver slettet. Hvornår skulle den ellers få lov til det? Vi ville bare få endnu flere problemer med vildtvoksende logfiler.

Jeg har netop siddet og kæmpet med 6 GB log der blev til 30 MB. På en harddisk der næsten var fuld.

Ingen point, du fik jo ikke rigtig noget ...

Endelig kan det jo sagtens være at der er andre eksperter der kender nogle workarounds som du kunne bruge, jeg er ikke .NET-mand, men kender den del til MSSQL. Så lad det da stå åbent et par dage, og rejs det evt i MSSQL-kategorien.

2 bemærkninger:

- loggen bliver ikke frigjordt ved commit, loggen bliver frigjordt ved enten
  backup eller checkpoint afhængig af recovery mode

- er det 2 phase commit du fisker efter ? du har f.eks. en SQLServer database
  og en Oracle database og du skal have en transaktion som retter i begge ?
  så kan du bruge 2 phase commit og en transaction manager (er indbygget i windows)

Men hvis commit ikke er sket frigøres den jo aldrig. Ifølge MS er det en almindelig grund til vildtvoksende logfiler.

Men hverken 2 phase commit eller transaction manager kender jeg til. Det er helt ikke tilfældigt at du har så mange point :o)

Så jeg vil lytte, hvis I kan finde ud af noget ...

jeg ville tro at transaktionen timede ud og blev rullet tilbage automatisk

men indrømmet jeg har aldrig prøvet

2PC er ikke nødvendigvis en løsning på problemet - det afhænger af konteksten

hvis konteksten er:
  sqlserver begin tx
  sqlserver execute stmt 1
  sqlserver execute stmt 2
  sqlserver commit tx
  snak med "noget andet" som ikke er SQLServer
  hvis det fejler så fortryd commit og lav rollback af SQLserver tx

og det der "noget andet" er XA compliant så kan man bruge 2PC

så kan man lave

transaction manager begin tx
sqlserver execute stmt 1
sqlserver execute stmt 2
noget andet execute stmt
transaction manager commit tx

de fleste seriøse database og message queues er XA compliant

transaction manager kan være: IBM TXSeries, BEA Tuxedo, MS Windows COM+ eller
en af de mange J2EE app-servere

hvor det klassiske tx eksempel er at du skal flytte 100 kr. fra en bank
konto til en anden bank konto

så må det klassiske 2PC eksempel være at du skal flytte 100 kr. fra en bankkonto
i database XXX (f.eks. SQLServer) til en anden bankkonto i database YYY (f.eks. Oracle)

Ja, det er faktisk det jeg skal bruge - har fundet nogle brugbare eksempler ved at google.

Tak for svaret arne, er der noget du ikke ved noget om - synes altid du svarer på mine spørgsmål :)

Smid endelig et svar så får du nogen points.

svar

du må kunne finde masser af stof om 2 phase commit, transaction managers,
XA compliant databaser og den slags på nettet