Es gibt keine feste Regel, aber ich sehe mehrere Gründe, Transaktionen von der Geschäftsebene aus zu kontrollieren:
-
Kommunikation über Datenspeichergrenzen hinweg. Transaktionen müssen nicht gegen ein RDBMS erfolgen; Sie können gegen eine Vielzahl von Entitäten gerichtet sein.
-
Die Möglichkeit, Transaktionen basierend auf Geschäftslogik rückgängig zu machen/festzuschreiben, die möglicherweise nicht für die bestimmte gespeicherte Prozedur verfügbar ist, die Sie aufrufen.
-
Die Fähigkeit, einen beliebigen Satz von Abfragen innerhalb einer einzigen Transaktion aufzurufen. Dadurch entfällt auch die Notwendigkeit, sich Gedanken über die Anzahl der Transaktionen zu machen.
-
Persönliche Präferenz:c# hat eine elegantere Struktur zum Deklarieren von Transaktionen:ein
usingBlock. Im Vergleich dazu habe ich Transaktionen innerhalb gespeicherter Prozeduren immer als umständlich empfunden, wenn ich zum Rollback/Commit springen wollte.
Dies kann ein Problem sein oder auch nicht, je nachdem, wie viele Transaktionen geöffnet werden (es ist nicht klar, ob dies ein einzelner Job oder eine Prozedur ist, die mit hoher Parallelität ausgeführt wird). Ich würde vorschlagen, zu prüfen, welche Sperren auf Objekte gesetzt werden und wie lange diese Sperren gehalten werden.
Denken Sie daran, dass die Validierung möglicherweise sollte sperren; Was passiert, wenn sich die Daten zwischen dem Zeitpunkt Ihrer Validierung und dem Zeitpunkt, an dem die Aktion ausgeführt wird, ändern?
Wenn es ist ein Problem, könnten Sie die problematische Prozedur in zwei Prozeduren aufteilen und eine von außerhalb eines TransactionScope aufrufen .
