Cam kết giao dịch máy chủ Sql lần ra

Question

Tôi gặp vấn đề lạ trong ứng dụng của mình. Nó xảy ra thực sự hiếm khi như một lần hoặc có thể là hai lần trong một tuần. Vì vậy, về cơ bản ở đây là tình huống:

Tôi có phương pháp này trong ứng dụng truy vấn DB nhiều lần, trước tiên có 4 lựa chọn, một trong số chúng sử dụng từ khóa UPDLOCK sau đó chèn vào bảng khác (không phải áp dụng UPDLOCK) và bản cập nhật trên bảng trước đây là UPDLOCK -ed.

Tất cả các truy vấn này được thực hiện trong một giao dịch (nằm ở bên cạnh .NET) và cuối cùng là COMMIT -ed.

Bây giờ, vấn đề là các transaction.Commit() ném ngoại lệ với thông điệp

Timeout hết hạn. Khoảng thời gian chờ trôi qua trước khi hoàn thành thao tác hoặc máy chủ không phản hồi

(như tôi đoán là SqlConnection lần).

Vì vậy, tôi có toàn bộ thủ tục này được bọc trong một khối try-catch và nếu ngoại lệ xảy ra tôi cố gắng để rollback giao dịch để khi điều này xảy ra thực thi mã đi vào catch khối và transaction.RollBack() được gọi và nó cũng ném ngoại lệ với thông điệp

SqlTransaction này đã hoàn thành. nó không còn có thể sử dụng

(như tôi đoán khi COMMIT lần ra giao dịch thực sự được COMMIT -ed), vì vậy sau này một số phần của ứng dụng messes lên. Điều được cho là không tồn tại (vì ROLLBACK) thực sự tồn tại và gây ra một số vấn đề không mong muốn sau đó được khắc phục thủ công (tại thời điểm này).

Tôi không thể tìm thấy bất kỳ điều gì có thể chỉ ra vấn đề có thể xảy ra, thay vì tăng thời gian chờ của SqlConnection. Nếu ai đó đã giải quyết vấn đề này trước khi bạn có thể chia sẻ kinh nghiệm, cảm ơn trước. (Các DB sử dụng máy chủ CPU không bao giờ đi trên 45-50%, là đa số trường hợp nó idles ở 3-15%)

Đây là lần đầu tiên Sql Chọn --Trước Chọn

SELECT TOP 1 
      t.Id , 
      t.OId , 
      t.Amount , 
    t.DUserId, 
      t.StartDate , 
      t.ExtDesc, 
    t.StatusId 
    FROM dbo.[Transaction] t 
      JOIN dbo.Wallet cw ON t.CId = cw.Id 
      JOIN dbo.Wallet dw ON t.DId = dw.Id 
    WHERE ExtKey = @ExtKey 
      AND (cw.vId = @vId 
        OR dw.VId = @vId 
       ) 

--Second Selct which executes twice with differenc params 


    SELECT u.Id , 
      UserName , 
      PinCode , 
      CurrencyId , 
      StatusId , 
      PersonalNumber , 
      gu.DefaultVendorServiceId , 
      CountryId, 
    u.FirstName, 
    u.LastName 
    FROM dbo.[User] u 
      LEFT JOIN dbo.GamblerUser gu ON gu.UserId = u.Id 
    WHERE u.Id = @UserId 


--Last select with (updlock) 


SELECT w.Id, AccountNo, FundTypeId, VendorServiceId, Balance, UserId, vs.IsLocalAccount 

FROM Wallet w (UPDLOCK) 
JOIN VendorService vs on w.VId = vs.Id 
WHERE 
    w.UserId = @UserId 
AND w.FundTypeId = @FundTypeId 
AND w.VendorServiceId = @VendorServiceId 


-- Insert 


    INSERT INTO [dbo].[Transaction] 
      (StartDate , 
       OTypeId , 
       StatusId , 
       Amount , 
       ExtDesc, 
       DUserId 
      ) 
    VALUES     (@StartDate , 
       @OTypeId , 
       @StatusId , 
       @Amount , 
       @ExtDesc, 
       @DUserId 
      ) 

    SET @Id = (SELECT @@IDENTITY 
      ) 


-- Update on updlocked table  


UPDATE dbo.Wallet SET 

    Balance = ISNULL(@Balance, Balance) 

WHERE Id = @Id 

Answer 1

(tôi giả sử đây không phải là Hekaton làm điều khác theo cam kết.)

Cam kết thường mất một lượng thời gian nhỏ. Một ghi vật lý phải đi vào nhật ký và trong trường hợp Mirroring/AG thì phải thực hiện một vòng lặp mạng. Một trong những điều đó có khả năng giữ cam kết ở đây.

Cá nhân tôi đã gặp sự cố này với kết nối Phản chiếu quá tải.

Thời gian chờ cam kết không thể thay đổi riêng biệt (mà tôi coi là lỗi). Thời gian chờ kết nối đang được sử dụng.

Điều tra nguyên nhân gốc mà tôi đã đề cập ở trên. Như một sự gia tăng workaround cam kết thời gian chờ.

Trong trường hợp cam kết không thành công, bạn không thể cho rằng giao dịch đã thực sự được cam kết hay không. (Đây là vấn đề hai tướng. Nó là unsolvable nói chung.) Bạn phải đưa ra một số loại kiểm tra để xem liệu cơ sở dữ liệu có chứa các dự kiến ​​viết hay không. Điều này phổ biến hơn trên Azure. Nhìn vào hướng dẫn Azure.