Neexistuje žádné pevné a rychlé pravidlo, ale vidím několik důvodů, proč kontrolovat transakce z obchodní úrovně:
-
Komunikace přes hranice datových úložišť. Transakce nemusí být proti RDBMS; mohou být proti různým entitám.
-
Schopnost vrátit zpět/potvrdit transakce na základě obchodní logiky, která nemusí být dostupná pro konkrétní uloženou proceduru, kterou voláte.
-
Schopnost vyvolat libovolnou sadu dotazů v rámci jedné transakce. To také eliminuje potřebu starat se o počet transakcí.
-
Osobní preference:c# má elegantnější strukturu pro deklarování transakcí:a
usingblok. Pro srovnání, vždy jsem zjistil, že transakce uvnitř uložených procedur jsou těžkopádné při přechodu na rollback/commit.
To může nebo nemusí být problém v závislosti na tom, kolik transakcí se otevírá (není jasné, zda se jedná o jednu úlohu nebo o proceduru, která je spouštěna s vysokou souběžností). Navrhoval bych podívat se na to, jaké zámky jsou umístěny na předmětech a jak dlouho jsou tyto zámky drženy.
Mějte na paměti, že ověření možná mělo zámek; co když se data změní mezi okamžikem, kdy jste je ověřili, a okamžikem, kdy došlo k akci?
Pokud je problém, můžete rozdělit problematickou proceduru na dvě procedury a jednu zavolat mimo TransactionScope .