Samtidighed ved database transaktioner

Transkript

1 Samtidighed ved database transaktioner Synopsis i WebDesign 4 sem. Kursus nr f07 Studerende: Vidar Jon Bauge Vejleder: Poul Henriksen Roskilde Handelsskole, 2007 Indholdsfortegnelse Indledning...2 Problemformulering...2 Spørgsmål...2 Problembeskrivelse...3 Disconnected Data Architecture...4 Namespaces...4 ADO.NET...5 Dataset...5.Net data provider objekter...6 SqlDataSource...7 Databinding...8 Typer af samtidighedshåndtering...9 Optimistisk samtidighed...9 Optimistisk samtidighed og Disconnected Data Architecture...10 Pessimistisk samtidighed...10 Last write wins...10 Optimistisk versus Pessimistisk samtidighed...11 Min implementering af disse...12 Webformene Show Customer og Optimistic Concurrency...12 Webformen Pessimistic Concurrency...13 Konklusion...15 Litteratur...16 Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 1 af 16

2 Indledning Webapplikationer henvender sig ofte til et stort publikum, hvor der vil optræde mange samtidige brugere. Hvis denne applikation, anvender en database, og interaktionen med brugere medfører at der sker ændringer i databasen, er det nødvendig at kontrollere adgangen til databasen så man undgår lost updates, som følge af samtidige opdateringer af de samme data. I denne synopsis vil jeg se på hvordan samtidighedsproblematikken kan håndteres i en.net webapplikation. Der findes 3 principper for samtidighedshåndtering. Disse vil blive nærmere beskrevet senere i denne synopsis. 1. Optimistic Concurrency 2. Pessimistic Concurrency 3. Last write wins Problemformulering Håndtering af databaser på.net platformen er bygget op omkring Disconnected data architecture. Som default håndteres samtidighedsproblematikken med optimistic concurrency, hvor data fra databasen gøres tilgængelig for webapplikationen ved at en eller flere rækker flyttes over i datasets der er tilgængelige for webapplikationen. Efter ændring af data, kan databasen opdateres, hvis der ikke er sket en ændring i de originale rækker i databasen efter at kopiering til datasets fant sted. Hvis dette er tilfældet, udføres transaktionen ikke, og der foreslås bl.a. i pensum at dette kan håndteres ved at brugeren får en fejlmeddelelse og bedes om at gentage sine transaktioner. Alternativt kan man anvende princippet last write wins, der i praksis ikke tager højde for samtidighedsproblematikken. Dette fremstår dog som meget risikabelt, i det der er fare for at databasen bliver inkonsistent eller at data ikke bliver korrekt opdateret (lost update). Spørgsmål 1. Hvordan kan situationer med mange samtidige transaktioner håndteres i en.net applikation? 2. Er optimistic concurrency tilstrækkeligt ved høje belastninger i applikationer der kræver få fejlmeddelelser? 3. Findes der alternativer til Disconnected data architecture og Optimistic concurrency der er bedre egnet til at håndtere disse situationer? Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 2 af 16

3 Problembeskrivelse Ovennævnte løsninger virker utilstrækkelige i en webapplikation, hvor man forventer mange, samtidige transaktioner på de samme data, og stiller krav til få fejlmeddelelser fra applikationen. Man kan f.eks. stille op følgende scenario: Man har en e-handels webapplikation, med nogle få meget populære produkter. Dvs mange (samtidige) forespørgsler på nogle få bestemte rækker. Hvis applikationen er designet således, at man ved bestilling opdaterer databasen, f.eks. lagerbeholdning vil man, ved optimistic concurrency, opleve at kunder afvises hvis mange kunder bestiller den samme vare samtidigt. Kunde A læser data for opdateringer. Inden han kan nå at fuldføre sin ordre, læser kunde B de samme data. Ved optimistic concurrency checkes dataene konsistens umiddelbart inden skrivning til databasen sker. Hvis 2 kunder har læst de samme data, vil derfor den der sidst er klar med sin ordre, og dermed skrivning til databasen, få en fejlmeddelelse og ordren vil blive afvist. En e-handels applikation er et eksempel på en webapplikation der ikke er tolerant overfor sådanne fejl, i det de er en ekstra belastning på kunden. Dette vil i den sidste ende gå udover omsætningen. Jeg vil i denne synopsis præsentere strukturen i ADO.NET og hvordan man anvender ADO.NET til at udføre søgning og transaktioner i en database. Jeg vil også kort skrive om databindings, for at vise hvordan tabeller kan knyttes til webcontroller i en webapplikation. Videre vil jeg tage Disconnected Data Architecture op, og se på mulighederne for at anvende både optimistisk og pessimistisk samtidighed indenfor denne arkitektur. Endelig vil jeg vurdere de 3 måder til samtidighedshåndtering i forhold til hverandre. Til denne synopsis, har jeg udvikle en enkel webapplikation, der viser hvordan optimistisk og pessimistisk samtidighedsbehandling fungerer på en tabel over kunder. Eftersom pessimistisk samtidighed ikke er direkte understøttet i.net på grund af disconnected data architecture, har jeg lavet en enkel implementation af denne. Denne implementering er enkel, og langt fra fuldkommen, men viser principene for hvordan jeg mener en pessimistisk samtidighedsbehandling kan implementeres fra en applikation, og hvor man udnytter disconnected data architecture til at reducere trafikken på databasen. For at begrænse denne synopsis, har jeg også udeladt de Exceptions der kan blive kastet ved transaktioner på en database. Dette er grunden til at min implementering ikke indeholder try-catch sekvenser, men baserer sig på at der ikke opstår fejlsituationer. Dette er naturligvis ikke acceptabelt i et produktionsmiljø, hvor applikationen skal tage højde for mulige exceptions, så den ikke standser. Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 3 af 16

4 Disconnected Data Architecture.Net data provider objektet er kun tilkoblet databasen idet det henter eller opdaterer databasen. Efter at data er hentet fra databasen, gøres de tilgængelig for applikationen i form af et dataset, der senere kan anvendes til at opdatere databasen. Af denne grund er optimistisk samtidighed det anvendte princip for samtidighedshåndtering. På denne måden, reduceres trafikken til databasen, fordi den enkelte bruger kun er tilkoblet databasen under læsning og skrivning. Namespaces. Alle ADO.NET objektene er implementeret i klasser i System.Data namespace, men de klasser der er specifikke for connection, kommando og data adaptere er afhængige af hvilken.net data provider der anvendes. Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 4 af 16

5 ADO.NET ADO.NET's grundlæggende opbygning Kilde: Murachs ASP.NET 2005 Arkitekturen i ADO.NET, består af 3 overordnede komponenter, eller objekter, nemlig et dataset, en.net dataprovider og selve databasen man kobler op imod. Dataset Dataset er helt centralt for disconnected data architecture, eftersom det indeholder en eller flere tabeller, der indeholder data der er hentet ud fra databasen, og som er læst ind i RAM, hvor de er direkte tilgængelig for applikationen. Datasettet består af en collection af tabeller, data om disse tabellerne, samt metoder der gør det muligt at ændre i dataene, og skrive dem tilbage til databasen. Datasettet er centralt, fordi det repræsenterer en ens interface til alle mulige datakilder, forskellige databaser etc, eftersom data hentes ind i et datasæt, bearbejdes i applikationen og derefter skrives tilbage til kilden. Dataset kan være typed og untyped. Et typed dataset, er defineret ud fra tabellerne i ens datakilde, og kan indholde metoder for datatilgang som man selv definerer. Anvendelsen af typed og untyped datasets i forbindelse med et SqlDataSource kan vises i følgende C# kode eksempel, hvor data hentes ud fra SqlDataSource1, hentes ned i et DataView, hvorfra det kan konverteres til først et untyped, og derefter et typed dataset: //Retrieve data through SglDataSource and place them in a DataView, then to a DataTable DataView dv = (DataView)SqlDataSource1.Select(DataSourceSelectArguments.Empty); DataTable ctable = dv.totable(); //Untyped dataset DataSet cuntypeddataset = new DataSet(); cuntypeddataset = ctable.dataset; //Typed dataset, which is already defined to hold a Customers table dscustomer ctypeddataset= new dscustomer(); ctypeddataset = (dscustomer) ctable.dataset; return ctypeddataset; Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 5 af 16

6 .Net data provider objekter.net data provider objektet består af tre komponenter, som jeg vil kigge nærmere på: Dataadapter Dataadapteren optræder som en forbindelse mellem den underliggende datakilde, og datasettet. Der findes flere forskellige typer dataadaptere, der er beregnet på forskellige typer datakilder eller forskellige databaser. I kodeeksemplet på næste side er der benyttet en OleDbDataAdapter, der indeholder metoder til læsning og manipulation af data i en database. Af andre dataadaptere, kan hurtig nævnes SqlDataAdapter der anvendes imod MS SQL Server og OracleDataAdapter der anvender Oracle's database. I kodeeksemplet på næste side anvendes 2 af dataadapterens metoder. Først anvendes en metode til at definere adapterens SELECT kommando, altså den SQL-kommando der anvendes til at hente data fra databasen. Dernæst anvendes dataadapterens Fill metode til at lægge dataene over i et datasæt, hvor de er tilgængelig for applikationen.. Udover dette indeholder dataadapteren metoder til UPDATE og DELETE. Command Command objektet repræsenterer SQL-kommandoer eller stored procedure for læsning og skrivning til databasen. Dets vigtigste attributter er SQL-kommander og et connection objekt. Hver type dataadapter har et tilsvarende type command objekt. Command objektets har constructorer der tager både både en SQL-kommando og eller en connection som parametre. Dette er naturligvis attributter der kan ændres, som vist i nedenstående kodeeksempel. Connection Dette objektet repræsenterer en forbindelse til databasen, og dets vigtigste attribut er en connection String der indeholder de oplysninger der skal til for at koble op imod databasen. I nedenstående tilfælde angives en data provider og stien til den anvendte database. En connection string kan også indeholde brugernavn og password. I en multi-tier applikation, også en angivelse af serverens URL og navnet på databasen. I kodeeksemplet på næste side vises hvordan en dataadapter kan anvendes til at fylde et dataset. Der oprettes et dataadapter objekt, et command objekt og et connection objekt. I følgende linjer kan man se hvordan objekterne tager hinanden som attributter, og på denne måden er forbundet: dataadapter.selectcommand = command; dataadapter.selectcommand.connection = connection; Dataadapteren har et command objekt som attributter, og command objektet har et connection attribut. Når dataadapterens fill metode kaldes, anvender dette command objektet til at få afviklet en SQLkommando. Command objektet anvender Connection objektet til at konnektere til databasen, og data læses gennem de 3 objekter, gennem dataadapteren hvorfra de placeres i datasettet. Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 6 af 16

7 private dscustomer getdataset1() { //Create a dataset dscustomer datasetcustomer = new dscustomer(); //Create a dataadapter object OleDbDataAdapter dataadapter = new OleDbDataAdapter(); //Create a command object OleDbCommand command = new OleDbCommand("SELECT * FROM Customers"); //Create a Connection object String constring = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\\Documents and Settings\\Vidar\\Dokumenter\\Visual Studio 2005\\WebSites\\Concurrency_project\\App_Data\\Northwind2.mdb"; OleDbConnection connection = new OleDbConnection(conString); dataadapter.selectcommand = command; dataadapter.selectcommand.connection = connection; dataadapter.fill(datasetcustomer); return datasetcustomer; } Anvendelse af de 3 objekter i en.net dataprovider SqlDataSource Eftersom jeg udelukkende har anvendt SqlDataSource i mit projekt, vil jeg kort beskrive dette. SqlDataSource er et objekt, der består af de 3 ovennævnte objekter. Når en SqlDataSource oprettes ved at trække det over i en webform, oprettes automatisk de nødvendige objekter, og ved hjælp af en wizard kan man definere dets SQL-kommandoer. Al kode til SQLDataSource lægges i aspx-filen, hvorfor man kan oprette og databinde en SQLDataSource til en webcontrol uden en code-behind fil i C#. Nedeunder ses et udsnit af en aspxfil med en definition af en SQLDataSource med SELECT, UPDATE og DELETE-kommandoer. <asp:sqldatasource ID="SqlDataSource2" runat="server" ConflictDetection="CompareAllValues" ConnectionString="<%$ ConnectionStrings:NorthWind2ConnectionString %>" DeleteCommand="DELETE FROM [Customers] WHERE [CustomerID] =? AND [CompanyName] =? AND [ContactName] =? AND [Address] =? AND [City] =? AND [PostalCode] =? AND [Phone] =?" InsertCommand="INSERT INTO [Customers] ([CustomerID], [CompanyName], [ContactName], [Address], [City], [PostalCode], [Phone]) VALUES (?,?,?,?,?,?,?)" OldValuesParameterFormatString="original_{0}" ProviderName="<%$ ConnectionStrings:NorthWind2ConnectionString.ProviderName %>" SelectCommand="SELECT [CustomerID], [CompanyName], [ContactName], [Address], [City], [PostalCode], [Phone] FROM [Customers] WHERE ([CustomerID] =?)" UpdateCommand="UPDATE [Customers] SET [CompanyName] =?, [ContactName] =?, [Address] =?, [City] =?, [PostalCode] =?, [Phone] =? WHERE [CustomerID] =? AND [CompanyName] =? AND [ContactName] =? AND [Address] =? AND [City] =? AND [PostalCode] =? AND [Phone] =?"> <DeleteParameters> <asp:parameter Name="original_CustomerID" Type="String" /> <asp:parameter Name="original_CompanyName" Type="String" /> Aspx kode der definerer parametre i en SqlDataSource Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 7 af 16

8 Databinding Databinding går ud på at man kan forbinde en webcontrol til en datasource. Controllen kan være en hvilken som helst control, der repræsenterer data, f.eks en DropDownList, RadioButtons etc eller de controller der er direkte lavet til at repræsentere data, som GridView, DetailsView, FomView etc. Databinding sker ved at man kobler en anvendte webcontrol til en datasource, der via sine SQL kommandoer, kan vise og opdatere data i databasen med webcontrollen som interface. Jeg vil af pladsmæssige hensyn vil jeg nøjes med at demonstrere hvordan jeg har anvendt dette i min applikation, hvor SqlDataSource er datakilde for en række DropDownLists og DetailsViews. Som tidligere nævnt, kan en SqlDataSource oprettes udelukkende i en aspx-fil, og sammenkoblingen mellem en datasource en web-control kan også finde sted her. Dette vises i nedenstående kodeeksempel: <asp:dropdownlist ID="DropDownList1" runat="server" AutoPostBack="True" DataSourceID="SqlDataSource1" DataTextField="CompanyName" DataValueField="CustomerID"> </asp:dropdownlist><asp:sqldatasource ID="SqlDataSource1" runat="server" ConnectionString="<%$ ConnectionStrings:NorthWind2ConnectionString %>" ProviderName="<%$ ConnectionStrings:NorthWind2ConnectionString.ProviderName %>" SelectCommand="SELECT [CustomerID], [CompanyName], [ContactName], [Address], [City], [PostalCode], [Phone], [Locked], [Lockid] FROM [Customers]"> </asp:sqldatasource> Her er en DropDownlist bundet til en SqlDataSource1, med definition af både dataprovider, connection String og en SELECT kommando. Bemærk også at attributten AutoPostBack er sat til true, og dermed gennemtvinger en postback, og opdatering af hele websiden når der vælges en ny værdi i DropDownListen. Databinding kan naturligvis også håndteres fra code-behind filen, hvor man på denne måden bedre kan kontrollere hvordan ens kontroller opfører sig i forhold til brugerens interaktioner og events der kan opstå. Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 8 af 16

9 Optimistisk samtidighed Typer af samtidighedshåndtering Ved optimistisk samtidighed, læses data fra databasen over i applikationen. Dataene gemmes i et dataset, der udover at holde styr på de data der oprindelig blev læst fra databasen også holder styr på de ændringer der er lavet fra applikationen. Når applikationen er færdig med sin redigering, data skal skrives tilbage til databasen, sker der først en sammenligning mellem de data der oprindelig blev hentet fra databasen og de tilsvarende poster i databasen. Hvis disse ikke er ens, har en anden bruger ændret i dataene, siden dataene blev læst ind. Der har altså været en samtidig transaktion, og en opdatering af databasen bliver afvist. Selve sammenligningen foregår ved hjælp af specielt udformede SQL UPDATE og DELETE kommandoer, med WHERE clauses der sørger for sammenligningen. Eftersom Optimistisk Samtidighed er direkte understøttet i.net, bliver disse SQL-kommandoerne automatisk genereret når man konfigurerer sin data-source, og man behøver ikke speciel kode i webformens code-behind fil, med mindre man ønsker at kontrollere om der er opstået problemer under opdateringen. Efter opdateringen af databasen, kan man få.net til at rejse en event, der indikerer om opdateringen er sket, eller om opdateringen er blevet forhindret som følge af samtidige transaktioner. Dette gøres ved at kontrollere om der er kastet en Exception, og ved at se på hvor mange rækker der rent faktisk er blevet opdateret. Hvis der er kastet en Exception, er der opstået en fejl, og hvis ingen rækker er blevet opdateret er man stødt på en samtidig transaktion. Hvordan dette UPDATE Customers Flowchart 1: Optimistisk Concurrency SET CompanyName =?, ContactName =?, Address =?, City =?, PostalCode =?, Phone =? WHERE (CustomerID =?) AND (CompanyName =?) AND (ContactName =?) AND (Address =?) AND (City =?) AND (PostalCode =?) AND (Phone =?) Update sætning fra Visual Studios Query Builder, der implementerer Optimistisk samtidighed. Den samme kommando kan genfindes i webformens aspx fil. implementeres i praksis, vil blive omtalt senere i denne synopsis, når jeg beskriver implementering af samtidighed i den webapplikation jeg har skrevet i forbindelse med denne synopsis. Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 9 af 16

10 Optimistisk samtidighed og Disconnected Data Architecture Denne måden at håndtere samtidighed på, passer som hånd i handske til Disconnected Data Architecture. Eftersom man kun har forbindelse til databasen i det øjeblik der læses og opdateres, ved databasen intet om de transaktioner der skal finde sted på de læste data. Derfor kan databasens faciliteter for låsning ikke anvendes. Samtidighedskontrol skal derfor håndteres fra applikationen, ved hjælp af de tidligere omtalte WHERE clauser. Pessimistisk samtidighed Princippet i pessimistisk samtidighed er at de records der læses for redigering, bliver låst i det øjeblik de læses, og forbliver låst indtil opdatering er fuldført. Dermed har ingen andre adgang til andet end læsning af de pågældende records, indtil den planlagte transaktion er fuldført. Dette var default i tidligere versioner af.net, inden man begyndte at anvende Disconnected Data Architecture. En stor ulempe ved denne metoden, er at forbindelsen til databasen opretholdes i hele transaktionens forløb, altså fra dataene læses fra databasen, mens redigering udføres, og til databasen bliver opdateret. Pessimistisk samtidighed er ikke understøttet i.net, og hvis man ønsker at anvende denne metode, skal man selv implementere den. Dette kan gøres i databasen, men kræver som tidligere nævnt at forbindelsen til databasen opretholdes, hvilket øger belastningen på databasen. En tredje mulighed er at håndtere dette i applikationen, indenfor rammerne af Disconnected data architecture. Flowchart 2: Pessimistisk Concurrency Dette kan med fordel klares ved at implementere klasser i applikations laget, der håndterer adgangen til databasen, så hele applikationen kan anvende de samme klasser til transaktioner i mod databasen. Last write wins Last write wins kan som sådan ikke omtales som samtidighedsbehandling, idet princippet er at den sidste transaktion overskriver tidligere transaktioner. Derfor går denne metoden ud på at ignorere problemet omkring samtidighed. Derfor kan last write wins kun anvendes i applikationer hvor man med sikkerhed ved at der aldrig nogensinde vil optræde mere end en bruger samtidigt. Eftersom dette er urealistisk for en webapplikation, vil jeg ikke bruge mere plads på denne metode her. Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 10 af 16

11 Optimistisk versus Pessimistisk samtidighed. Der findes en række fordele og ulemper ved de 2 metoder at håndtere samtidighed på, noget som jeg har prøvet at fremstille i denne tabel. Når man skal implementere datahåndtering i.net, er det selvfølgelig det enkleste at anvendelse optimistisk samtidighed. Simpelthen fordi dette er direkte understøttet af udviklingsplatformen, hvorimod man selv skal implementere pessimistisk samtidighed. Udover dette skal man overveje hvordan man ønsker at ens applikation skal opføre sig når flere brugere samtidigt arbejder på de samme data. I de fleste tilfælde vil optimistisk samtidighed ikke medføre større ulempe for brugeren end hvad der anses for acceptabelt. Hvis man derimod ønsker at brugeren advares inden redigering af data påbegyndes. F.eks. fordi man forventer at problemer med samtidighed ofte opstår, eller man vil undgå at brugerens ændringer afvises pga samtidighed, skal man overveje pessimistisk samtidighedshåndtering. Ved implementering af pessimistisk samtidighed, skal man overveje om den skal implementeres ved hjælp af databasens mekanismer for samtidighedskontrol, eller om man selv skal implementere sine låse. Her vil overvejelserne gå på om databasen tillader læseadgang til låste data, adgang til oplysninger om de låste data, f.eks hvem der har låsen. I tillæg skal man overveje problemstillinger omkring vedvarende forbindelser til databasen i forbindelse med pessimistisk samtidighed. Fordele Ulemper Optimistisk Samtidighed Understøttet i.net Kan anvendes indenfor Disconnected data architecture Ingen advarsler om samtidighed før update. Brugeren kan ikke få opdateret sine ændringer, selvom de er færdige Alle records altid tilgængelig for læsning Pessimistisk Samtidighed i databasen Tillader advarsel om samtidighed før redigering. Kan implementeres ved hjælp af databasens låse. Forbindelsen til databasen må opretholdes under redigering, til opdatering kan gennemføres. Pessimistisk Samtidighed i databasen i applikationen Tillader advarsel om samtidighed før redigering. Kan anvendes indenfor Disconnected data architecture Kræver at man selv implementerer låse, og metoder for disse i applikationen. Kan kræve understøttelse for at fjerne en lås i utide, f.eks. timeout. Det er lettere at administrere data omkring hvem der har låst. Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 11 af 16

12 Min implementering af disse Jeg har lavet en lille webapplikation der implementerer pessimistisk og optimistisk samtidighed. Jeg har valgt at implementere den pessimistiske lås i applikationen, fordi jeg på denne måden kan vise hvordan den implementeres i C# i Visual Studio. I et produktionsmiljø, vil man måtte overveje at samle denne funktionalitet i nogle centrale funktionsklasser eller anvende databasens faciliteter til formålet. Ideen bag applikationen, er at give adgang til en tabel i en database med mulighed for at ændre i dens data. Ved at oprette flere sessioner, kan man fremkalde samtidighedsproblemer som applikationen skal håndtere med pessimistisk og optimistisk samtidighedshåndtering. Pessimistisk samtidighedshåndtering er implementeret ved at tilføje 2 kolonner til den anvendte tabel, kolonnerne locked og lockid, der holder oplysninger om rækken er låst og hvem der har låsen. Ved indlæsning for redigering ændres indholdet i disse felter, så de angiver at rækken er låst og af hvem. Min webapplikation består af 3 webforms, som jeg vil gennemgå i det følgende. Udover dette har jeg implementeret en webform hvor man kan skrive et brugernavn, så man anvende forskellige brugernavne i de forskellige sessioner man vælger at åbne. Denne vil ikke blive gennemgået, idet den udelukkende gemmer et brugernavn i en session variabel så man kan identificere hvem der har låst en række. Webformene Show Customer og Optimistic Concurrency Disse webformene er næsten ens, idet de består af 2 webcontroller. En DropDownList der lader brugeren vælge en kunde, og en DetailsView hvori man kan se detaljer om den valgte kunde. De 2 vigtigste forskelle på Show Customer og Optimistic Concurrency, er at man i Show Customer får vist de feltene der indeholder oplysninger om låsen, nemlig Locked og Lockid. I webformen Optimistic Concurrency er der desuden tilføjet en edit knap, så man kan redigere den enkelte række. Som datakilder er anvent en SqlDataSource, der er konfigurereret til UPDATE med optimistisk samtidighed. Den tilsvarende SqlDataSource i Show Customer, er konfigureret uden UPDATE og DELETE kommandoer. Code behind filen til Show Customer er faktisk tom, fordi alt fra konfigurering af SqlDataSource og databinding foregår i selve aspx filen. (Se tidligere kodeeksempler) Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 12 af 16

13 Code behind filen til Optimistic Concurrency består af en metode der udføres ved ændringer i det item webformens DetailsView. Efter en ændring checkes der om der blev genereret en Exception, og hvor mange rækker der blev påvirket af UPDATE. Hvis der blev genereret en exception betyder det at der opstod en fejl, under UPDATE. Hvis antal ændrede rækker er 0, er der opstået en concurrency error. I begge tilfældet vises en fejlmeddelelse. Optimistic concurrency error protected void DetailsView1_ItemChanged(object sender, DetailsViewUpdatedEventArgs e) { if (e.exception!= null) { Label2.Text = "An error occured during upate!"; Label4.Text = "Data has not been altered, Please try again later."; e.exceptionhandled = true; e.keepineditmode = true; } else if (e.affectedrows == 0) { Label3.Text = "A concurrency exception has occurred!"; Label4.Text = "Data has not been altered, Please try again later."; } else Label4.Text = "Updated with success"; Label5.Text = "Operation completed"; }//DetailsView1_ItemChanged Metode fra pessimistic.aspx.cs, der checker om der er opstået en fejl eller concurrency error ved UPDATE fra DetailsView Webformen Pessimistic Concurrency Denne webformen har jeg lavet manuelt ved at præsentere det enkelte felt i en separat TekstBox, med et tilhørende Label der viser hvilken kolonne det enkelte felt viser data fra. Kunden vælges, som i de andre webforms med en DropDownList. Datakilderne er 2 SqlDataSource, en der henter og opdaterer feltene med kundeoplysningerne og en der udelukkende håndterer feltene med låsen, altså Lock, og Lockid. Jeg har valgt at gøre det på denne måden for at få bedst mulig kontrol med afviklingen af programkoden, idet jeg på denne måden kunne programmere det hele selv. Når brugeren har valgt kunde ved hjælp af DropDownListen, bliver data hentes oplysninger om kunden ud i et DataView, hvorfra det enkelte felt kan hentes ud som strenge, og vises i den enkelte TextBox. Ved klik på Edit knappen, kontrolleres først om den aktuelle record er låst. Låsen læses ind, som ved kundeoplysningerne, ved hjælp af et DataView. private void getlock() { DataView dv = (DataView)SqlDataSource2.Select(DataSourceSelectArguments.Empty); dv.rowfilter = "CustomerID = '" + DropDownList1.SelectedValue + "'"; DataRowView dvrow = (DataRowView)dv[0]; } locked = dvrow["locked"].tostring(); lockid = dvrow["lockid"].tostring(); Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 13 af 16

14 Hvis den pågældende record er låst, skrivebeskyttes TextBoxene, dataene vises, og brugeren præsenteres for en fejlmeddelelse. Hvis record'en ikke er låst, gøres TextBoxene skrivbare. Efter redigering, kan brugeren anvende knappen Update. Så opdateres dataene i databasen, låsen frigøres, og TextBoxene bliver igen skrivebeskyttet. Skrivning til databasen sker ved at anvende SqlDataSourcens Updatemetode og UpdateParameter attributter, som vist i nedenstående kodeeksempel, hvor låsen bliver sat: Fejlmeldelse ved låst record private void lockrecord() { SqlDataSource2.UpdateParameters["CustomerID"].DefaultValue = Session["Selected"].ToString(); SqlDataSource2.UpdateParameters["Locked"].DefaultValue = "Y"; SqlDataSource2.UpdateParameters["Lockid"].DefaultValue = Session["user"].ToString(); SqlDataSource2.Update(); } Pessimistic concurrency error fremkaldt ved at åbne 2 sessioner, der arbejder på de samme data. Denne metode til at låse data i databasen arbejder indenfor rammerne af Disconnected Data Architecture, fordi man kun har forbindelse til databasen i det øjeblik data læses fra, og skrives til, databasen. Når dataene er læst ind, kaldes en metode der læser de kolonner der indeholder låsen. Hvis dataene er låst, sørger applikationen for at der ikke kan redigeres, og at de metoder der skriver data tilbage til databasen ikke er tilgængelig for brugeren. F.eks ved at fjerne eller disable Update knappen. Den største mangel i denne implementering, er mangelen på en time-out funktion. Dette er noget som vil være påkrævet, for at sikre at data i databasen ikke forbliver låst efter fejlsituationer som f.eks. nedbrud i applikationen. Implementering af en timeout funktion på låsen skal også klares i applikationen, men er udeladt fra denne synopsis af pladshensyn. Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 14 af 16

15 Konklusion I denne konklusion vil jeg prøve at besvare de spørgsmål jeg har stillet til denne synopsis: Hvordan kan situationer med mange samtidige transaktioner håndteres i en.net applikation? Der findes kun 2 brugbare metoder til at håndtere samtidige transaktioner i en.net applikation, optimistisk og pessimistisk samtidighedshåndtering. Det letteste er at anvende de metoder der er understøttet af platformen (optimistisk), fordi dette ikke kræver at man selv implementerer samtidighedsbehandling. Man kan dog selv implementere pessimistisk samtidighed, men så skal man nøje vurdere om dette står i forhold til eventuelle fordele. Er optimistic concurrency tilstrækkeligt ved høje belastninger i applikationer der kræver få fejlmeddelelser? Her må min konklusion være at pessimistisk samtidighed er godt egnet til applikationer med mange samtidige transaktioner. Man kan dog tabe ændringer fordi data er blevet låst under redigering..nets disconnected data architecture, med optimistisk samtidighed, må også siges at være skalerbar, i det reduktionen i antal database forbindelser frigør kapacitet på databasen. Denne frigjorte kapacitet betyder at der er plads til flere samtidige brugere. Man kan ikke ved forskellige måder at håndtere samtidighed på, forhindre at data bliver låst for opdatering af andre brugere. Hvis man udvikler en applikation der ikke er tolerant for fejlsituationer, bør man så vidt muligt undgå at brugere får problemer med samtidighed. Hvis man nu går tilbage til det scenario jeg præsenterede tidligere i denne synopsis, med en e- handles applikation, kan man opnå dette på følgende måde: Lagerbeholdningen opdateres ikke som følge af at en kunde opretter en ordre. Ved at lade kunden oprette en ny bestilling, anvendes ikke UPDATE, men INSERT der ikke er udsat for disse problemer. Så kan man overlade til personale at opdatere i databasen, og dermed skulle håndtere samtidighed. Findes der alternativer til Disconnected data architecture og Optimistic concurrency der er bedre egnet til at håndtere disse situationer? Udover pessimistisk samtidighedshåndtering, kan man anvende Last write wins. Eftersom denne metode håndterer samtidighed ved at ignorere problemet, kan den ikke anses at være et alternativ. Ved at anvende pessimistisk eller optimistisk samtidighedshåndtering får man applikationer der håndterer disse situationer på forskellige måder. Der findes intet endeligt svar på hvilken måde der er den rigtige, og systemudviklere må vurdere disse problemstillingene for den enkelte applikation. Kun på denne måden kan man sikre sine data imod inkonsistens, samtidig med at ens applikation giver de ønskede fejlmeddelelser på de ønskede tidspunkter. Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 15 af 16

16 Litteratur Murach's ASP.NET 2.0 Web Programming with C# 2005 by Joel Murach and Anne Boehm ISBN Roskilde Handelsskole, 2007 Vidar Jon Bauge Side 16 af 16