Các chiến lược giao tác: : Hiểu những cạm bẫy trong giao tác ppt

Các chiến lược giao tác: : Hiểu những cạm bẫy trong giao tác

Đề phòng các lỗi thường gặp khi triển khai thực hiện giao tác trên nền Java

Mark Richards, Giám đốc và kiến trúc sư kỹ thuật cao cấp, Collaborative

Consulting, LLC

Tóm tắt: Xử lý giao tác phải đạt được tính toàn vẹn và nhất quán của dữ liệu ở

mức cao. Bài viết này, là bài đầu tiên trong một loạt bài viết về phát triển một

chiến lược giao tác hiệu quả trên nền Java, sẽ giới thiệu những cạm bẫy thường

gặp để ngăn bạn khỏi mắc vào. Dùng những ví dụ là các đoạn mã lệnh trong

Spring Framework và đặc tả EnterPrise JavaBeans (EJB) 3.0, tác giả Mark

Richards sẽ giải thích những lỗi quá thông thường ấy.

Lý do chung nhất khi sử dụng các giao tác trong một ứng dụng là để duy trì tính

toàn vẹn và nhất quán của dữ liệu ở mức cao. Nếu bạn không quan tâm đến chất

lượng dữ liệu của mình, thì bạn cũng không cần quan tâm đến các giao tác. Sau

hết, việc hỗ trợ giao tác trên nền Java có thể hủy hoại hiệu năng, sinh ra vấn đề về

khóa và các vấn đề tương tranh trong cơ sở dữ liệu, và do vậy gây thêm phức tạp

cho trình ứng dụng của bạn.

Về loạt bài này

Các giao tác làm tăng chất lượng, tính toàn vẹn và tính nhất quán của dữ liệu của

bạn, và khiến cho các trình ứng dụng của bạn vững chãi hơn. Việc triển khai thể

hiện thành công các xử lý giao tác trong các ứng dụng Java không phải là một

công việc tầm thường, và đây là nói về việc thiết kế cũng quan trọng ngang với nói

về viết mã lệnh. Trong loạt bài mới này, Mark Richards sẽ hướng dẫn chúng ta

thiết kế một chiến lược giao tác hiệu quả cho một loạt các trường hợp từ các trình

ứng dụng đơn giản cho đến xử lý giao tác hiệu năng cao.

Nhưng những người phát triển lại không bận tâm đến những giao tác gây thiệt hại

cho mình như thế. Hầu hết các ứng dụng có liên quan đến kinh doanh đều yêu cầu

chất lượng dữ liệu ở mức cao. Chỉ riêng ngành kinh doanh đầu tư tài chính đã mất

mười tỉ đô la cho các hoạt động thương mại thất bại, mà dữ liệu tồi là nguyên nhân

thứ hai dẫn tới tình trạng này (xem Tài nguyên). Mặc dù việc thiếu các hỗ trợ giao

tác chỉ là một tác nhân dẫn đến tình trạng dữ liệu tồi (vẫn là nguyên nhân chính),

một kết luận chắc chắn là hàng tỷ đô la đã bị lãng phí chỉ riêng trong lĩnh vực kinh

doanh đầu tư tài chính là hậu quả của việc thiếu hụt hoặc không có các hỗ trợ giao

tác.

Không biết gì về các hỗ trợ giao tác là nguyên nhân khác của vấn đề. Rất thường

xuyên tôi đã nghe những tuyên bố theo kiểu “chúng tôi không cần hỗ trợ giao tác

trong các trình ứng dụng của chúng tôi đâu, bởi vì chúng chả bao giờ lỗi cả.”

Đúng. Tôi đã từng chứng kiến một số trình ứng dụng trong thực tế cực hiếm hoặc

không bao giờ đưa ra các báo lỗi. Những trình ứng dụng ấy trông cậy vào việc có

mã lệnh viết rất tốt, có các thủ tục kiểm tra dữ liệu hợp lệ được viết tốt và việc hỗ

trợ kiểm soát mã và kiểm thử đầy đủ để giảm chi phí thực thi và những phức tạp

liên quan đến xử lý giao tác. Vấn đề của cách suy nghĩ như thế là ở chỗ nó chỉ tính

đến một đặc trưng của hỗ trợ giao tác: tính nguyên tử . Tính nguyên tử đảm bảo

rằng mọi cập nhật sẽ được xem như một đơn vị công việc duy nhất và, hoặc là tất

cả được giao kết hoặc là tất cả bị hủy bỏ. Nhưng sự hủy bỏ hoặc phối hợp các cập

nhật không phải là khía cạnh duy nhất của hỗ trợ giao tác. Một khía cạnh khác, sự

phân lập, sẽ đảm bảo rằng mỗi đơn vị công việc được tách biệt khỏi các đơn vị

khác. Nếu không có sự phân lập giao tác thích hợp, các đơn vị công việc khác có

thể truy nhập vào các cập nhật được tạo ra bởi một đơn vị công việc đang chạy,

mặc dù đơn vị này chưa hoàn thành xong việc của mình. Và kết quả là các quyết

định kinh doanh có thể được đưa ra dựa trên dữ liệu chưa hoàn chỉnh, gây ra

những giao dịch kinh doanh thất bại hoặc những hậu quả tiêu cực.

Muộn còn hơn không

Tôi bắt đầu đánh giá đúng các vấn đề trong xử lý giao tác từ đầu năm 2000, khi

làm việc cho khách hàng tôi để ý đến một mục trong bản kế hoạch dự án ngay bên

trên nhiệm vụ kiểm thử hệ thống. Dòng đó là thực hiện hỗ trợ giao tác. Chắc chắn

rồi, khá dễ dàng bổ sung các hỗ trợ giao tác vào trình ứng dụng chính khi nó gần

như đã đến giai đoạn sẵn sàng để kiểm thử hệ thống có phải không? Thật không

may, cách tiếp cận này quá chung chung. Ít nhất thì dự án này, không giống như

hầu hết những dự án khác, đã thực thi các hỗ trợ giao tác, mặc dù ở giai đoạn cuối

của chu kỳ phát triển.

Vậy thì khi đã biết rằng chi phí cao và ảnh hưởng xấu của dữ liệu tồi và các hiểu

biết cơ bản về giao tác là quan trọng (và cần thiết), bạn cần sử dụng các giao tác và

học cách giải quyết các vấn đề nảy sinh. Bạn gấp rút bổ sung hỗ trợ giao tác vào

trình ứng dụng của mình. Và đây chính là chỗ mà các vấn đề thường nảy sinh. Các

giao tác hình như thường không hoạt động như hứa hẹn trên nền Java. Bài viết này

sẽ khảo sát tỉ mỉ lý do tại sao như thế. Cùng với sự trợ giúp của các đoạn mã ví dụ,

tôi sẽ giới thiệu những cạm bẫy phổ biến trong giao tác mà tôi thường thấy và kinh

nghiệm trong lĩnh vực này, hầu hết trường hợp là trong các môi trường sản xuất.

Mặc dù hầu hết các đoạn mã ví dụ trong bài viết này sử dụng khung công tác

Spring (Spring Framework) phiên bản 2.5, khái niệm giao tác là tương tự như

trong đặc tả EJB 3.0. Trong đa số các trường hợp, chỉ đơn giản là ta thay thế lời

chú giải @Transactional của khung công tác Spring bằng @TransactionAttribute