Closes issue #6384

Code Change Summary

Overview

Added SERIALIZABLE transaction isolation to three MovePage stored procedures in 10.01.00.SqlDataProvider to prevent race conditions that could create duplicate TabOrder values.

Files Modified

• DNN Platform/Website/Providers/DataProviders/SqlDataProvider/10.01.00.SqlDataProvider

Changes Made

1. Transaction Isolation Level

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

• Added to beginning of each procedure to force sequential execution
• Prevents concurrent reads of the same TabOrder data

2. Explicit Transaction Management

BEGIN TRANSACTION
-- [Original procedure logic]
COMMIT TRANSACTION

• Wrapped all operations in explicit transactions
• Ensures atomicity of multi-step TabOrder updates

3. Error Handling

BEGIN TRY
    -- [Procedure logic]
    COMMIT TRANSACTION
END TRY
BEGIN CATCH
    ROLLBACK TRANSACTION
    THROW
END CATCH

• Added comprehensive error handling with automatic rollback
• Preserves database consistency on failures

Procedures Updated

• MoveTabAfter: Move tab to position after specified tab
• MoveTabBefore: Move tab to position before specified tab
• MoveTabToParent: Move tab to new parent with automatic positioning

Key Benefits

• ✅ Eliminates Race Conditions: Forces sequential execution of concurrent requests
• ✅ Preserves Logic: No changes to existing business rules or calculations
• ✅ Backward Compatible: Same procedure signatures and behavior
• ✅ Data Integrity: Guarantees unique TabOrder values within parent/portal scope

Impact

• Minimal Code Changes: Only transaction control additions
• Database-Level Fix: No application layer modifications required
• Performance Consideration: SERIALIZABLE isolation may increase latency under high concurrency but is not a concern because the concurrent use of this feature is very limited.

Test Results

Screenshot showing initial database state with proper TabOrder sequencing

Console output showing test execution under sequential conditions

Screenshot showing database maintains proper TabOrder uniqueness after sequential execution

Console output showing test execution under concurrent conditions demonstrating race condition. The other 2 conflicting operations are rejected by the database.

Screenshot showing no duplicate TabOrder values created by concurrent execution