Transaktioner för olika Connections...?

Ska väl fungera att använda olika Connections med ett Transaktionsobjekt? det har jag i alla fall för mig :)

Att "dela" en transaktion över flera objekt känns inte som rätt väg att gå. Vad exakt försöker du göra?

r) Mitt 6 000:e inlägg på wF!

Nu vet jag inte hur ditt datalager fungerar. Men om du inte behöver använda dig av two-phase-commit. Alltså en transaktion över flera connections så fungerar det utmärkt med ADO.NET's Transactionern.

Fråga är alltså om den data som du vill INSERTA skall in i en och samma databas, så fall behövs inte 2-phase commit. Det är bara du som har ett dåligt datalager om det inte klara av Transactioner över flera bussinesobjekt.

Mitt datalager/objectmapperlager klarar av Transactioner över flera olika BussinessObjekt, så länge de alla använder samma connectionstrings.

Det jag gör är att jag låter mitt Datalager skapa en ADO.NET Transaction som jag skickar tillbaka till mitt businesslager, denna transaction håller nu en öppen connection till min databas.

För varje businessobjekt som jag spara så skickar jag med mitt transactionsobjekt, typ så här.

SqlTransaction transaction = ObjectMapper.BeginTransaction();
try{
orderRow.Save(transaction);
orderHeader.Save(transaction);
customer.Save(transaction);

ObjectMapper.CommitTransaction(transaction);
}catch(Exception exception){
 ObjectMapper.RollbackTransaction(transaction);
}

Det är all kod som behövs i mitt businesslager för att spara ner en orderrad, orderheader och customerobject med transactioner.

Visst kan du använda dig av COM+ även om jag tycker det verkar onödigt i ditt fall, men jag kanske missat något. Det är inte så svårt, läs på om ServicedComponents det tar en dags pulande sedan har du koll på det.

- M

Gladh: Ja, det var det jag var ute efter!

Vad jag gör är att jag har en Webservice som anropar 2 metoder som ligger i två olika klasser i mitt BL.

Så, om jag gör som du, dvs. att jag låter mitt DAL/DL skicka tillbaka ett Transaktions-objekt, som jag sedan skickar med till de olika BL-anropen, så bordet det fungera även för mig...!

Min fundering i detta fallet är att jag ju måste deklarera Transaktions-objektet i min klient (Webservicen), vilket kanske inte känns helt arkitekturiskt rätt...

Jag provar, Tack!

Om du har en Webservice som skall hantera Transactionen så skulle jag göra så som jag har gjort i mitt exempel.

Att deklarera Transaktions-objektet i Webservicen är inte fel, med tanke på att Webservicen tillhör ditt BusinessLager och du lär få skapa din Transaction i ditt BusinessLager eftersom det är där som den används.

Om du inte vill göra så som jag har gjort så måste du komplicerar till det rätt friskt i ditt DL eftersom du då måste starta din Transaction, och på något sätt hålla denna iliv frams till du kallar på Commit/Rollback. Och sedan måste alla dina anrop till ner till DataLagret på något sätt luska ut om det finns en transaction öppen och använda sig av denna. Man måste också kolla så det är rätt transaction eftersom du garanterat kan ha flera användare samtidigt.

Det går att lösa och du får samma effekt, bara det att du aldrig får tillbaka något transactionsobjekt uppe i ditt BussinesLager. Men igengäld så får du ett mer komplext DataLager. Eftersom det faktiskt kan komma anrop till databasen från din kod som inte skall använda sig av transactioner.

Så, om jag gör som du, dvs. att jag låter mitt DAL/DL skicka tillbaka ett Transaktions-objekt, som jag sedan skickar med till de olika BL-anropen, så bordet det fungera även för mig...!

Om det fungerar för dig vet jag faktiskt inte :) eftersom det beror på hur du har skrivit ditt DAL.

När du skapar en Transaction så skapas en koppling till databasen, som läggs i transactionen, denna koppling är öppen ända tills du gör en Commit/Rollback. Det betyder att ditt DataLager måste kunna klara av att använda sig av denna öppna koppling istället för att skapa en ny, om du skickar med en Transaction till ditt DL.

- magnus