Best Practices für Transaktionen

Question

Wie sehr verlassen Sie sich auf Datenbanktransaktionen?

Bevorzugen Sie kleine oder große Transaktionsbereiche?

Bevorzugen Sie clientseitige Transaktionsverarbeitung (z. B. TransactionScope in .NET) über Server Seitentransaktionen oder umgekehrt?

Was ist mit verschachtelten Transaktionen?

Haben Sie einige Tipps & Tricks im Zusammenhang mit Transaktionen?

Irgendwelche Probleme mit der Transaktion?

Alle Arten von Antworten sind willkommen.

Answer 1

Ich verwende Transaktionen bei jeder Schreiboperation in die Datenbank.
So gibt es einige kleine "Transaktionen" in einer größeren Transaktion verpackt und im Grunde gibt es eine ausstehende Transaktionsanzahl im Schachtelungscode. Wenn beim Beenden des Parents noch ausstehende Kinder vorhanden sind, wird alles zurückgesetzt.

Ich bevorzuge clientseitige Transaktionsverarbeitung, wo verfügbar. Wenn Sie auf sps oder andere serverseitige logische Arbeitseinheiten angewiesen sind, sind serverseitige Transaktionen in Ordnung.

Answer 2

Ich wickle immer eine Transaktion in einer using-Anweisung.

using(IDbTransaction transaction) 
{ 
// logic goes here. 
    transaction.Commit(); 
} 

Sobald die Transaktion den Gültigkeitsbereich verlässt, wird sie entsorgt. Wenn die Transaktion noch aktiv ist, wird sie zurückgesetzt. Dieses Verhalten scheitert daran, dass Sie die Datenbank versehentlich sperren. Selbst wenn eine unbehandelte Ausnahme ausgelöst wird, wird die Transaktion immer noch zurückgesetzt.

In meinem Code lasse ich explizite Rollbacks aus und verlasse mich auf die using-Anweisung, um die Arbeit für mich zu erledigen. Ich führe nur explizit Commits durch.

Ich habe festgestellt, dass dieses Muster die Sperrprobleme drastisch reduziert hat.

Answer 3

Persönlich, die Entwicklung einer Website, die hohe Traffic-Performance basiert, bleiben ich von Datenbanktransaktionen wann immer möglich. Offensichtlich sind sie notwendig, deshalb verwende ich ein ORM und Objektvariablen auf Seitenebene, um die Anzahl der Server-Seitenanrufe zu minimieren, die ich machen muss.

Verschachtelte Transaktionen sind eine großartige Möglichkeit, um Ihre Anrufe zu minimieren, ich gehe in diese Richtung, wann immer ich kann, solange es sich um schnelle Abfragen handelt, die keine Sperrung verursachen. NHibernate war in diesen Fällen ein Retter.

Answer 4

Wow! Viele Fragen!

Bis vor einem Jahr verließ ich mich zu 100% auf Transaktionen. Jetzt sind es nur 98%. In speziellen Fällen von stark frequentierten Websites (wie Sara erwähnt) und auch hochpartitionierten Daten, die die Notwendigkeit verteilter Transaktionen durchsetzen, kann eine transaktionslose Architektur verwendet werden. Jetzt müssen Sie die referenzielle Integrität in der Anwendung codieren.

Auch ich mag Transaktionen deklarativ mit Anmerkungen verwalten (ich bin ein Java-Typ) und Aspekte. Das ist eine sehr saubere Möglichkeit, Transaktionsgrenzen zu bestimmen, und es enthält Funktionen zur Transaktionsfortpflanzung.

Answer 5

Dies ist ein interessanter Link für Verschachtelung T-SQL-Transaktionen: http://aleemkhan.wordpress.com/2006/07/21/t-sql-error-handling-pattern-for-nested-transactions-and-stored-procedures/

Answer 6

So wie ein FYI ... Verschachtelte Transaktionen gefährlich sein kann. Es erhöht einfach die Chancen auf einen Deadlock. Also, obwohl es gut und notwendig ist, ist die Art, wie es implementiert wird, wichtig in Situationen mit höheren Volumina.

Answer 7

Wie Sara Chipps sagte, ist die Transaktion für Anwendungen mit hohem Traffic Overkill. Also sollten wir es so weit wie möglich vermeiden. Mit anderen Worten, wir verwenden einen BASE architecture anstelle von ACID. Ebay ist ein typischer Fall. Verteilte Transaktionen werden in der Ebay-Architektur überhaupt nicht verwendet. Aber für eventual consistency müssen Sie selbst einen Trick machen.

Answer 8

Server-Seite Transaktionen, 35.000 Transaktionen pro Sekunde, SQL Server: 10 lessons from 35K tps

Wir Server-Seite Transaktionen nur benutzen können später und beenden früher

nicht

tun verteilt starten

• können Arbeit vor und nach
• SET XACT_ABORT ON bedeutet sofortiges Rollback bei Fehler
• Client/OS/Treiber Agnostiker

Sonstiges:

• wir Nest aber @@ TRANCOUNT zu erkennen bereits begonnen TXNs
• jeder DB-Aufruf verwenden Anrufe immer Atom

Wir mit Millionen von INSERT-Zeilen pro Tag zu tun haben (einige, die über Staging-Tabellen in Stapel zusammengefasst wurden), volle OLTP, keine Probleme. Aber nicht 35k tps.