.NET-ympäristö tarjoaa muutamia toisistaan poikkeavia tekniikoita tietokantojen transaction-käsittelyn toteuttamiseksi. Oma näkemykseni on, että tyylin, miten tietokantakyselyiden transaction-käsittely hoidetaan, tulee mukautua kulloinkin kyseessä olevan kyselyiden sarjan tai esimerkiksi sovellusarkkitehtuurin luonteeseen. Lisäksi transaktioille saatetaan joutua asettamaan erityisiä vaatimuksia, jolloin aivan perinteisimmät tekniikat eivät enää yksinkertaisesti riitä. Esittelen siis seuraavissa “.NET-transaktiot”-blogikirjoituksissa muutamia erilaisia tekniikoita, joiden avulla on mahdollista hoitaa oman järjestelmän tietokantakyselyiden transaction-käsittely. Samalla pyrin tarkastelemaan hieman sitä, mihin erilaisiin tilanteisiin kyseiset tekniikat voisivat kulloinkin soveltua.

Ensimmäisenä esiteltävistä transaction-tekniikoista tarkasteluun otetaan .NET:n Data Provider:ien tarjoamat perinteisimmät transaktiot ja .NET Framework 2.0:n tarjoama System.Transactions.TransactionScope-transaktioluokka. Kyseisten tekniikoiden huomattavin ero liittyy niiden kykyyn hallita useamman tietokantayhteyden transaktioita. Data Provider:ien tarjoamien transaktioiden avulla voidaan siis hallita ainoastaan tietokantakyselyitä, joissa käytetään yhteen tietokantaan kohdistuvaa tietokantayhteyttä. System.Transactions.TransactionScope-palvelun avulla voidaan sen sijaan hallita lisäksi niin sanottuja “hajautettuja transaktioita” (distributed transactions), jolloin tietokantakyselyiden yhteydet kohdistuvat eri tietokantoihin. Puhuttaessa hajautetuista transaktoista voidaan usein törmätä teknologiaan nimeltä “MSDTC” (Microsoft Distributed Transactions Coordinator). Kyseinen teknologia toimii hajautettujen transaktoiden koordinaattorina, joka valvoo transaktion toteutumista useamman tietokannan välillä ( aiheesta lisätietoa ).

Miksi sitten käyttäisin perinteistä Data Provider:ien transaktio-mallia, kun tarjolla on suoraan TransactionScope-palvelun tarjoama tekniikka useamman tietokantayhteyden transaktioon? Syy tähän saattaisi löytyä esimerkiksi siitä, että Data Provider:t (esim. SqlClient, OleDb, Odbc, OracleClient) on suunniteltu toimimaan nimenomaan kullekkin Provider:lle tarkoitetun tietokannan kanssa, joten suorituskyky transaktoiden kohdalla on myös varmasti parhaimmillaan. Itse pyrin luomaan transaktiot esimerkiksi siten, että mikäli kyseessä on yksinkertainen yhdessä metodissa suoritettava kysely tai kyselyiden sarja, niin hyödynnän perinteistä transaktio-mallia. Mikäli sitten tietokantakyselyt suoritetaan useamman eri metodin kautta, niin hyödynnän TransactionScope-palvelun transaktio-tekniikkaa. Tällöin kyselyissä käytettävää tietokantayhteyttä ei tarvitse siis kuljettaa metodilta toiselle, joka tukee varmasti aina sovelluksen arkkitehtuurin eheyttä paremmin.

Lopuksi jotta kukaan ei jäisi kylmäksi, esittelen pienen perustason koodiesimerkin, missä havainnollistetaan esiteltyjen transaction-tekniikoiden käyttöä. Koodi on kommentoitu hyvin, joten siitä pitäisi olla helppoa ymmärtää ydin ajatukset.

Transaction-esimerkki

Postaukseen lisätty oikaisu 2.10.2010:

Tämähän ei siis pidä täysin paikkaansa, sillä ADO.NET:n tarjoamien transaktioiden avulla voidaan hallita myös “hajautettuja transaktioita” käyttämällä hyväksi tietokantayhteys-objektin (esim. SqlConnection) EnlistTransaction-metodia, joka tuli uutena .NET:n piiriin .NET-framework 2.0:n myötä. Tämän myötä voidaan siis todeta, että suurin ero ADO.NET:n ja System.Transactions transaktoiden välillä liittyy niiden tapaan muodostaa transaction-käsittelyn “viitekehys”. ADO.NET:n transaktoita voidaan siis pitää tässä suhteessa “manuaalisena”, jolloin uusien tietokantayhteyksien liittäminen transaction-kehykseen täytyy suorittaa manuaalisesti, kun taas System.Transactions.TransactionScope liittää aina automaattisesti kaikki viitekehyksen piirissä avatut tietokantayhteydet samaan kehykseen. Viitekehyksellä tarkoitan tässä tapauksessa sitä kehystä, jonka piirissä valvotaan transaction-käsittelyn onnistumista (comit), jolloin virheiden ilmaantuessa kaikki tehdyt toiminnot kehyksen sisällä peruuntuu (rollback).

aihe: dotNet