2008-09-02 17 views
25

Bạn dựa vào giao dịch cơ sở dữ liệu bao nhiêu?Thực tiễn tốt nhất về giao dịch

Bạn có thích phạm vi giao dịch nhỏ hoặc lớn không?

Bạn có thích xử lý giao dịch phía khách hàng hơn (ví dụ: TransactionScope in .NET) trên máy chủ giao dịch bên hoặc ngược lại không?

Điều gì về giao dịch lồng nhau?

Bạn có một số mẹo & các thủ thuật liên quan đến giao dịch không?

Bất kỳ gotchas nào bạn gặp phải khi làm việc với giao dịch?

Tất cả các loại câu trả lời đều được chào đón.

Trả lời

3

Tôi sử dụng giao dịch trên mọi thao tác ghi vào cơ sở dữ liệu.
Vì vậy, có một vài "giao dịch" nhỏ được bao bọc trong giao dịch lớn hơn và về cơ bản có số lượng giao dịch chưa thanh toán trong mã lồng nhau. Nếu có bất kỳ trẻ em xuất sắc khi bạn kết thúc phụ huynh, tất cả các con quay lại.

Tôi thích xử lý giao dịch phía máy khách nếu có. Nếu bạn bị xuống hạng để làm sps hoặc các đơn vị logic phía máy chủ khác của công việc, giao dịch phía máy chủ là tốt.

+0

Giao dịch phía khách hàng ??! –

18

Tôi luôn bao bọc giao dịch trong tuyên bố sử dụng.

using(IDbTransaction transaction) 
{ 
// logic goes here. 
    transaction.Commit(); 
} 

Khi giao dịch chuyển ra ngoài phạm vi, nó sẽ được xử lý. Nếu giao dịch vẫn hoạt động, giao dịch sẽ được khôi phục. Hành vi này không bảo vệ bạn khỏi vô tình khóa cơ sở dữ liệu. Ngay cả khi một ngoại lệ không được giải quyết được ném, giao dịch vẫn sẽ quay trở lại.

Trong mã của tôi, tôi thực sự bỏ qua các lần xuất hiện rõ ràng và dựa vào báo cáo sử dụng để thực hiện công việc cho tôi. Tôi chỉ thực hiện một cách rõ ràng các cam kết.

Tôi đã tìm thấy mẫu này đã giảm đáng kể các sự cố khóa ghi.

8

Cá nhân, phát triển một trang web dựa trên lưu lượng truy cập cao, tôi tránh xa các giao dịch cơ sở dữ liệu bất cứ khi nào có thể. Rõ ràng họ là cần thiết, vì vậy tôi sử dụng một ORM, và các biến đối tượng cấp trang để giảm thiểu số lượng các cuộc gọi phía máy chủ tôi phải thực hiện.

Giao dịch lồng nhau là cách tuyệt vời để giảm thiểu cuộc gọi, tôi chỉ đạo theo hướng đó bất cứ khi nào tôi có thể miễn là chúng là các truy vấn nhanh sẽ không gây ra khóa. NHibernate đã là một vị cứu tinh trong những trường hợp này.

2

Wow! Rất nhiều câu hỏi!

Cho đến một năm trước, tôi dựa vào 100% giao dịch. Bây giờ chỉ có 98% của nó. Trong trường hợp đặc biệt của các trang web lưu lượng truy cập cao (như Sara đã đề cập) và cũng có dữ liệu được phân đoạn cao, thực thi nhu cầu giao dịch phân tán, kiến ​​trúc giao dịch có thể được chấp nhận. Bây giờ bạn sẽ phải mã toàn vẹn tham chiếu trong ứng dụng.

Ngoài ra, tôi muốn quản lý giao dịch một cách khai báo sử dụng chú thích (Tôi là một anh chàng Java) và các khía cạnh. Đó là một cách rất rõ ràng để xác định ranh giới giao dịch và nó bao gồm chức năng tuyên truyền giao dịch.

2

Cũng như một FYI ... giao dịch lồng nhau có thể nguy hiểm. Nó đơn giản làm tăng cơ hội bị bế tắc. Vì vậy, mặc dù nó là tốt và cần thiết, cách nó được thực hiện là quan trọng trong tình hình khối lượng cao hơn.

0

Như Sara Chipps cho biết, giao dịch quá mức cần thiết cho các ứng dụng lưu lượng truy cập cao. Vì vậy, chúng ta nên tránh nó càng nhiều càng tốt. Nói cách khác, chúng tôi sử dụng BASE architecture thay vì ACID. Ebay là một trường hợp điển hình. Giao dịch phân tán không được sử dụng trong kiến ​​trúc Ebay. Nhưng đối với eventual consistency, bạn phải tự mình thực hiện một số thủ thuật.

2

giao dịch phía Server, 35.000 giao dịch mỗi giây, SQL Server: 10 lessons from 35K tps

Chúng tôi chỉ sử dụng máy chủ giao dịch bên:

  • có thể bắt đầu sau đó và kết thúc sớm hơn
  • không phân phối
  • có thể làm làm việc trước và sau
  • Đặt XACT_ABORT BẬT nghĩa là khôi phục ngay lập tức về lỗi
  • client/OS/tài xế bất khả tri

khác:

  • chúng tôi tổ cuộc gọi nhưng sử dụng @@ trancount để phát hiện TXNs đã bắt đầu
  • mỗi cuộc gọi DB luôn luôn là nguyên tử

Chúng tôi đối phó với hàng triệu hàng INSERT mỗi ngày (một số được sắp xếp theo các bảng dàn), OLTP đầy đủ, không có vấn đề gì. Không phải là 35k tps.