-
Notifications
You must be signed in to change notification settings - Fork 2
SqlTopicRepository.Save(): Wrap recursive in a single transaction #155
Copy link
Copy link
Open
Labels
Area: SQLRelates to the SQL Server database objects; do not use for the repository.Relates to the SQL Server database objects; do not use for the repository.Priority: 3Severity 1: MinorStatus 0: DiscussionNeeds further evaluation of requirements and prioritization.Needs further evaluation of requirements and prioritization.Type: BugBehavior that is inconsistent with documented or expected behavior.Behavior that is inconsistent with documented or expected behavior.
Description
Activity
Metadata
Metadata
Assignees
Labels
Area: SQLRelates to the SQL Server database objects; do not use for the repository.Relates to the SQL Server database objects; do not use for the repository.Priority: 3Severity 1: MinorStatus 0: DiscussionNeeds further evaluation of requirements and prioritization.Needs further evaluation of requirements and prioritization.Type: BugBehavior that is inconsistent with documented or expected behavior.Behavior that is inconsistent with documented or expected behavior.
Currently, a recursive
Save()issues a separateSqlConnection/SqlCommandper topic via theCreateTopic/UpdateTopicstored procedures, with no transaction spanning the entire operation. If persistence fails partway through a large recursive save, the topics processed so far are left committed inTopicswhile the remainder are not, leaving the tree in a partially-saved state with no way to roll back or safely retry.Implementation Notes
SqlTopicRepository.Save()(and its recursion) should open a singleSqlTransactionfor the full recursive operation—covering everyCreateTopic/UpdateTopic/MoveTopiccall issued during that save—and commit only once every topic in the tree has been persisted successfully. On any failure, the transaction should roll back so the database is left exactly as it was before the save began, rather than in a partial state.Given the existing
CreateTopic/MoveTopicstored procedures already useSERIALIZABLE/TABLOCKfor their own nested-set arithmetic, the transaction should be scoped to avoid holding that lock for the full duration of a very large recursive save where avoidable; this will require some care.Affected Files
OnTopic.Data.Sql/SqlTopicRepository.csTasks
Save()persistence loop in a singleSqlTransactionSave()in its XML doc comments