0
ausführen Mit

ich eine Menge Leute in meinem Unternehmen tun dies zu sehen:Transaction wählen

var transactionOptions = new System.Transactions.TransactionOptions(); 
transactionOptions.IsolationLevel = System.Transactions.IsolationLevel.ReadUncommitted; 

using (var transactionScope = new System.Transactions.TransactionScope(System.Transactions.TransactionScopeOption.Required, transactionOptions)) 
{ 
    try 
    { 
     using (DefaultContext ctx = new DefaultContext()) 
     { 
      return ctx.Item.Where(x => x.State == 1); 
     } 
    } 
    catch (Exception err) 
    { 
     throw err; 
    } 
    finally 
    { 
     transactionScope.Complete(); 
    } 
} 

Sie wirklich eine Transaktion zu einem Select I und schließlich Complete() -Methode öffnen müssen nenne ich dachte dass es nur für Datenmodifikation war ...

Jemand kann mir erklären, ob es richtig ist? Ist es eine gute oder schlechte Praxis? Ist es nicht notwendig?

dank

+1

Es scheint völlig unnötig. Es kann schnell laufen, aber ich würde den Overhead nicht übernehmen. Ich verwende nur scoped txns mit Einfügungen und Updates. Ich sehe, dass dies den 'IsolationLevel' auf' ReadUncommitted' setzt. Sie tun dies möglicherweise für den NOLOCK-Effekt, der bereitstellt. –

+1

'ReadUncommitted' erlaubt unsaubere Lesevorgänge, was bedeutet, dass Sie Daten von nicht festgeschriebenen Abfragen in Ihren Lesevorgängen sehen können (siehe https://stackoverflow.com/questions/2471055/why-use-a-read-uncommitted-isolation-level) * ist nicht * der Standard, aber das 'catch/throw'-Konstrukt ist völlig unnötig. –

+1

Haben Sie jemanden in Ihrer Firma gefragt, warum sie das tun? ;) Ich stimme @R zu. Richards, es sieht für mich so aus, als ob der einzige Grund dafür ist, die Isolationsstufe Read Uncommitted zu verwenden. Dies deutet darauf hin, dass es (oder an einem bestimmten Punkt) ein Problem mit dem Sperren gab, das die Anwendung behinderte, so dass ReadUncommitted verwendet wurde, um Leselocks zu vermeiden. IMO, dies ist eine ziemlich große Datenzugriffsänderung (um auf der ganzen Linie zu verwenden), also würde ich hoffen, dass jemand die ganze Geschichte kennen würde. Oder vielleicht hat eine Person das einmal gemacht und jetzt ist es ein Copy/Paste-Problem. –

Antwort

2

Also, was ein Transaktionsbereich sinnvoll wäre, für, wenn Sie eine Menge Dinge mit der Datenbank tun. Nehmen wir an, Sie modifizieren 3 Tabellen. Sie ändern Tabelle 1 Tabelle 2, aber wenn Sie versuchen, Tabelle 3 zu ändern, schlägt es fehl. Sie möchten nicht, dass die Änderungen in den Tabellen 1 und 2 beibehalten werden, wenn das 3. fehlgeschlagen ist. Dies ist, wo Sie es in einen Transaktionsbereich umbrechen, da im Falle eines Fehlers alle diese Änderungen rückgängig gemacht werden (oder eher nicht) und Sie sich nicht darum kümmern müssen.

Sie können mehr here lesen.

Wrapping einer Abfrage in einem Transaktionsbereich, nur um Daten zu bekommen ... Ich sehe keinen Vorteil. Sie haben Recht, es gibt keine Datenmanipulation, daher muss es wirklich keinen Transaktionsbereich geben. Ich gehe davon aus, dass einige Ihrer Kollegen gerade gesehen haben, dass jemand anderes sie benutzt, und dass sie entschieden haben, dass es eine gute Idee wäre, wenn sie es auch tun würden.

Eine weitere Kuriosität ist die Tatsache, dass sie den Transaktionsbereich schließlich abschließen. Wenn ein Fehler ausgegeben wurde, möchten Sie wahrscheinlich keine Transaktion abschließen.

+0

Sie haben Recht. Sie kopieren und hinterlegen die Transaktion für jeden Codeblock im Projekt ... "Sie hatten keine Zeit zu fragen, warum". Ihre Antwort war sehr hilfreich, Mann. Vielen Dank! –

Verwandte Themen