2011-12-08 16 views
18

Sử dụng Entity Framework, tôi nhận được một số ngoại lệ sau đêm qua tại một trong những ứng dụng của tôi:System.Data.EntityException: Các nhà cung cấp tiềm ẩn thất bại trên Commit

System.Data.EntityException: The underlying provider failed on Commit. ---> 
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior 
to completion of the operation or the server is not responding.  
    at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection) 
    at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()  
    at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error) 
    at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj) 
    at System.Data.SqlClient.TdsParserStateObject.ReadNetworkPacket()  
    at System.Data.SqlClient.TdsParserStateObject.ReadBuffer()  
    at System.Data.SqlClient.TdsParserStateObject.ReadByte()  
    at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler,SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)  
    at System.Data.SqlClient.TdsParser.TdsExecuteTransactionManagerRequest(Byte[] buffer, TransactionManagerRequestType request, String transactionName, TransactionManagerIsolationLevel isoLevel, Int32 timeout, SqlInternalTransaction transaction, TdsParserStateObject stateObj, Boolean isDelegateControlRequest) 
    at System.Data.SqlClient.SqlInternalConnectionTds.ExecuteTransactionYukon(TransactionRequest transactionRequest, String transactionName, IsolationLevel iso, SqlInternalTransaction internalTransaction, Boolean isDelegateControlRequest)  
    at System.Data.SqlClient.SqlInternalConnectionTds.ExecuteTransaction(TransactionRequest transactionRequest, String name, IsolationLevel iso, SqlInternalTransaction internalTransaction, Boolean isDelegateControlRequest) 
    at System.Data.SqlClient.SqlInternalTransaction.Commit()  
    at System.Data.SqlClient.SqlTransaction.Commit() 
    at System.Data.EntityClient.EntityTransaction.Commit()  
    --- End of inner exception stack trace ---  
    at System.Data.EntityClient.EntityTransaction.Commit()  
    at System.Data.Objects.ObjectContext.SaveChanges(SaveOptions options)  
    at System.Data.Entity.Internal.InternalContext.SaveChanges()  
    at System.Data.Entity.Internal.LazyInternalContext.SaveChanges() 

Điều thú vị về lỗi này là dữ liệu đã thực sự được ghi vào cơ sở dữ liệu. Tôi found a related post on a MS site dường như cho biết đây là lỗi liên quan đến mạng.

Một vài câu hỏi mà tôi có thể sử dụng sự hỗ trợ trên là:

  1. Những tùy chọn sao tôi phải rắc rối shoot lỗi này?
  2. Có nhiều khả năng mạng liên quan hoặc DB có thể là một nghi phạm không?
  3. Làm cách nào để tôi biết mã giao dịch có thực sự hoàn tất không?
  4. Tôi có nên truy vấn DB về lỗi này để kiểm tra xem thành công hay đơn giản là thử lại giao dịch?
  5. Nếu tôi thử giao dịch lại, làm thế nào điều này có thể được thực hiện tự động với Khung thực thể hoặc tôi chỉ cần bắt/thử lại?
  6. Tôi nên xem những mặt hàng nào khác?

Xin cảm ơn trước.

CẬP NHẬT

Sử dụng Ignite for SQL chúng tôi có thể xác định rằng một quá trình SQL thứ cấp từ một nhóm khác được độc chiếm CPU ngăn chặn ứng dụng của chúng tôi từ hoạt động bình thường. Tóm lại, chúng tôi đang tiến lên phía trước với việc thêm một máy chủ phụ để ngăn chặn xung đột hơn nữa giữa hai đội.

Điều thú vị về ngoại lệ là giao dịch thực sự thành công hơn là không thành công.

+0

Tôi biết đã lâu rồi, nhưng bạn có thể giải thích về cách bạn sử dụng Ignite cho SQL không? Trong trường hợp của tôi nó không phải luôn luôn xảy ra vì vậy thật khó để biết khi nào để xem máy chủ. – gitsitgo

+0

Không thể nói rằng tôi là một guru đốt cháy; chúng tôi có nhóm hiệu suất DB xử lý nội dung này. Tôi có thể nói rằng những gì tôi thường tìm kiếm khi tôi nhận được các vấn đề hiệu suất là báo cáo sql hàng đầu (như đốt cháy các tiểu bang "các thanh lớn"). Đó thường là các truy vấn hogging tất cả mọi thứ. Từ đó nó là vấn đề điều chỉnh các truy vấn đó. Xin lỗi vì tôi không thể cung cấp thêm chi tiết cụ thể mà bạn đang tìm kiếm. Chúc may mắn. – Randy

Trả lời

1

Đặt cược của tôi là phản hồi thành công từ lệnh cam kết giao dịch không được gửi (hoặc không được gửi đủ nhanh) gây ra một ngoại lệ trong mã của bạn. Một trường hợp cạnh điên rồ. Ngoại lệ của loại này không nhất thiết có nghĩa là việc thực thi lệnh thực tế thất bại chỉ có một số A không thành công.

Tương tự như vậy nếu có sự cố khi gửi phản hồi từ cuộc gọi webservice, điều đó không nhất thiết ngụ ý rằng bất kỳ tác dụng phụ nào của cuộc gọi đó đều không được áp dụng.

+0

Luke, Cảm ơn bạn đã bình luận. Bạn chắc chắn có ý tưởng đúng. Tôi đã nhìn thấy điều tương tự trong mã WS nơi WS xử lý yêu cầu nhưng phản hồi đã hết thời gian chờ. Thúc đẩy tôi hạt khi điều này xảy ra khi bạn không có cách nào để "biết" nếu những thứ thực sự làm việc; đó là trừ khi bạn muốn mã hóa các dịch vụ có thể được gọi để xác minh rằng mọi thứ thực sự đã hoạt động. ;-) – Randy

+1

@Randy thực sự là một điều rất giống với mạng máy tính với TCP. Hiệu trưởng là nếu chúng tôi không nhận được xác nhận rằng thư được gửi, chúng tôi thử lại cho đến khi chúng tôi thực hiện, tuy nhiên điều này có nghĩa là thông báo (trong trường hợp này là giao dịch cơ sở dữ liệu) phải là idempotent (tức là có thể phát lại). giao dịch cơ sở dữ liệu –

0

+1 cho Luke, việc khám phá rất tốt. Từ ngữ lỗi là không may.

System.Data.EntityException: **The underlying provider failed on Commit.** ---> 
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior 

cần được đọc

System.Data.EntityException: **The underlying provider failed to respond to Commit** 
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior 

những nguyên nhân có khả năng là những vấn đề mạng hoặc máy chủ. ví dụ như 100 CPU, hoặc chậm trễ máy chủ khác, tất cả vẫn chính xác. NHƯNG bạn KHÔNG BIẾT nếu nó đã cam kết hay không, nếu đây là một trường hợp thời gian chờ. Nếu nhận được phản hồi không thành công, DB phải quay trở lại. Tất nhiên nếu điều đó không xảy ra, thì DB đã bị rơi ummm và dẫn đến hỏng hóc tiềm ẩn. Hiếm tôi hy vọng.

Tôi đã thấy trong bảng 1 tỷ + hàng ...Trong thời gian phân bổ không gian dưới sự tăng trưởng, vì chỉ mục và vùng dữ liệu cần mở rộng, mất hơn 30 giây. NHƯNG DI CHUYỂN COMMIT DID. Khách hàng đã hết thời gian chờ. Tổ chức lại trực tuyến cũng có thể gây ra sự chậm trễ như vậy (ít nhất tôi thấy rằng trên DB2 ít nhất)