Java EE: Tại sao sử dụng JTA trực tiếp?

Question

Tôi đang cố gắng hiểu JTA và đang sử dụng Bitronix làm Người quản lý giao dịch được lựa chọn (chỉ vì lợi ích của việc học và hiểu). Tôi đang xem mã bên trong Bitronix reference guide here và tự hỏi mình: Nếu tôi đang sử dụng JDBC, bản thân nó là giao dịch (Connection có thể được cam kết/cuộn lại), tại sao tôi lại muốn viết mã như thế? !?!

Bây giờ có thể điểm của đoạn mã đó chỉ đơn giản là minh họa cách sử dụng Bitronix/JTA trên kho dữ liệu giao dịch hiện có, nhưng tôi vẫn không nhận được những lợi ích vốn có mà nó cung cấp. Sau đó, đoạn mã này khiến tôi suy nghĩ: "Nếu chỉ có hai nguồn dữ liệu chính bạn sử dụng là cơ sở dữ liệu và nhà môi giới thư, và bạn sử dụng JDBC/JMS để giao tiếp với họ tương ứng, và hai tiêu chuẩn này (JDBC/JMS) đã được giao dịch, sau đó tại sao bạn sẽ cần phải sử dụng JTA ở tất cả?!? "

JTA là một loại Java EE API" bên trong "mà JDBC, JPA, JMS, v.v ... sử dụng; và chỉ được công khai tiếp xúc với 1% ers trên mạng mà muốn làm điều gì đó điên rồ với nó? Hoặc tôi có thiếu ý tưởng/ứng dụng của JTA hoàn toàn không? Tôi đoán tôi có thể hình dung ra hai trường hợp sử dụng không phải JDBC và không phải JMS để đánh trực tiếp vào JTA, nhưng vì tôi quá mờ nhạt về JTA ở nơi đầu tiên tôi không biết liệu những trường hợp này có off-track hay không. :

• Có thể bạn có hệ thống I/O phức tạp trong ứng dụng của mình và có nhiều chủ đề đọc/ghi từ cùng một tệp trên đĩa. Có lẽ bạn sẽ có mỗi thread sử dụng một giao dịch để ghi vào tập tin này. (Có?!? Không?!?)
• Có lẽ bạn có một máy trạng thái POJO đại diện cho trạng thái của một hệ thống và nhiều luồng có thể sửa đổi máy. Có lẽ bạn sẽ có mỗi thread sử dụng một giao dịch để thay đổi trạng thái của máy.

Tôi đoán ở thư mục gốc của câu hỏi của tôi là (Có Không?!?!?):

• Nếu JPA của tôi (Hibernate) và/hoặc các cuộc gọi JDBC đã giao dịch, tại sao tôi muốn bọc chúng bên trong JTA bắt đầu-> commit/rollback block? Ditto cho JMS và hệ thống nhắn tin.
• Bên ngoài JPA/JDBC/JMS, trường hợp sử dụng nào tồn tại để sử dụng JTA để giao dịch một loạt các hoạt động?

Xin cảm ơn trước!

Answer 1

Nó không chỉ là quay trở lại giao dịch mở, JTA cung cấp giao diện XAResource mà nhà cung cấp có thể triển khai, trình điều khiển JDBC và nhà cung cấp JMS của bạn đã làm điều này và bạn có thể thực hiện. Điều này được dựa trên một tiêu chuẩn mở và có lẽ đáng đọc.

Bây giờ, tại sao chúng ta lại muốn điều này?

Cân nhắc Matthews ví dụ trong một thảm họa:

Begin DB Transaction 

Set AccountBalance $100 lower for Account #345 in database 

Add JMS Message "Transfer $100 to OtherBank Account #987" to queue 

*** DB power is unplugged while committing DB Transaction *** 

Đáng tiếc là thông điệp JMS đã đi đến bờ bên kia, đây là một vấn đề rất thực tế với các giao dịch phân tán.

Với XA đây là cách kịch bản sẽ diễn ra:

DB Transation starts XA Transaction 

Set AccountBalance $100 lower for Account #345 in database 

JMS Connection joins XA Transaction 

Add JMS Message "Transfer $100 to OtherBank Account #987" to queue 

Everything went okay and JTA context is ready to commit. 

DB and JMS both agree that they are capable of commiting. 

JTA instructs DB and JMS to commit. 

All members of the transaction commit. 

Bây giờ bạn có thể yêu cầu những gì sẽ xảy ra nếu cắm điện được kéo ra trong thập niên DB thức cam kết. Vâng, hàng đợi JMS sẽ được cam kết, tuy nhiên giao dịch XA sẽ vẫn mở cho đến khi DB lại một lần nữa, lúc đó nó sẽ hướng dẫn DB thực hiện (DB đã hứa với chúng ta rằng nó có thể cam kết, đây là một phần của việc tuân thủ XA).

Điều thực sự tuyệt vời về JTA là bạn có thể dễ dàng triển khai XAResource tùy chỉnh của riêng bạn và gắn vào khung công tác tuyệt vời này!

CẬP NHẬT

Vì vậy, để trả lời câu hỏi của bạn về việc khi thực hiện giao dịch tùy chỉnh, bạn có thể tự hỏi mình như sau:

1. là trạng thái tùy chỉnh của bạn hoặc tập tin không thể là khối mã cuối cùng trong phạm vi giao dịch?
2. Bạn có cần hoàn nguyên trạng thái/tệp tùy chỉnh của mình khi hệ thống bên ngoài (ví dụ: DB hoặc JMS) không?
3. Là một getRollbackOnly đơn giản() & setRollbackOnly() cho các hệ thống bên ngoài, cùng với xử lý bồi thường (nghĩa là hoàn nguyên trạng thái/tệp tùy chỉnh) cho mã tùy chỉnh của bạn không đủ?

Nếu câu trả lời cho cả 1, 2 & 3 là CÓ thì bạn có thể muốn có một XAResource tùy chỉnh, nếu không tôi nghĩ rằng đó có lẽ là quá mức cần thiết.

Tuy nhiên nếu mã của bạn là khung hoặc thư viện sẽ được nhập ngũ theo logic kinh doanh trong không gian Java EE, bạn có thể muốn triển khai XAResource cho nó!

Answer 2

Bạn có thể có một giao dịch bao gồm cả cơ sở dữ liệu và dịch vụ tin nhắn. Tôi không biết cách nào để làm điều đó mà không có JTA.

Ví dụ khái niệm đơn giản.Mã chính xác là không quan trọng:

Begin JTA giao dịch

Set AccountBalance $ 100 thấp hơn cho tài khoản # 345 trong cơ sở dữ liệu

Thêm JMS Message "Chuyển $ 100 đến OtherBank Tài khoản # 987" phải xếp hàng

Cam kết giao dịch JTA

OtherBank là ngân hàng riêng biệt và chúng tôi giả định bạn liên lạc với nó o ver JMS.

Giao dịch bắt đầu và cam kết được xử lý bởi JTA. Nếu thêm nó vào hàng đợi không thành công, việc rút tiền cũng sẽ tự động quay trở lại.

Cuộc sống thực không phải là quá đơn giản, nhưng điều này sẽ cung cấp cho bạn một ý tưởng.

EDIT:

JTA thể được sử dụng bất kỳ phần nào thời gian của hệ thống có thể thực hiện một cách chính xác các XAResource. Bằng cách thực hiện điều đó, một tài nguyên có thể tham gia vào các giao dịch được phân phối. Thoạt nhìn, cả hai ví dụ được đề xuất của bạn có thể có thể triển khai XAResource.

"hệ thống I/O phức tạp trong ứng dụng của bạn và có nhiều chủ đề đọc/ghi từ cùng một tệp trên đĩa". - Nghe có vẻ như nó có thể là một cơ sở dữ liệu, nếu bạn nghĩ về nó.

"Có lẽ bạn có một máy trạng thái POJO đại diện cho trạng thái của hệ thống và nhiều luồng có thể sửa đổi máy." - Điều này chắc chắn có thể là một ứng cử viên, nếu thay đổi có thể được cô lập đầy đủ.

Tôi nghĩ phần đầu tiên của phiếu đánh giá về cơ bản là các tài nguyên logic có thể là XAResource s. Nói cách khác, khái niệm về ACID có ý nghĩa. Thứ hai là có thể và đáng để nỗ lực triển khai giao diện đó (nơi nó chưa được triển khai).

Answer 3

Theo ý kiến ​​của tôi, xem xét đầu tiên là để trang trí cho người quản lý TX và hệ thống TX.

Khi tôi thiết kế ứng dụng của mình, từ Giao dịch đánh dấu ý định của tôi là làm điều gì đó ACID. Tôi muốn đặt ý định này vào mã kinh doanh của tôi vì điều này cần được thúc đẩy bởi nhu cầu kinh doanh.

tôi mong đợi một cái gì đó kỳ diệu (container của tôi trong cuộc sống thực) sẽ dệt intents tx của tôi một cách chính xác, tùy thuộc hệ thống cơ bản TX (cơ sở dữ liệu, JMS môi giới, vv)

Hơn nữa, JTA định nghĩa giao diện Somes để cho phép tích hợp giữa một hệ thống JTA hiện có và một hệ thống TX (cuối cùng mới, cuối cùng kỳ lạ). Ví dụ: GigaSpaces XAP là một DataGrid trong bộ nhớ. Nó không phải là JMS, không phải SQL, nhưng thật dễ dàng để làm cho nó như là it provides a JTA integration. Chúng tôi có thể báo giá nhiều sản phẩm khác ...

Rõ ràng, ví dụ sát thủ là sự hỗ trợ cho các giao dịch XA giữa các hệ thống khác nhau (tôi đưa ra một điểm cho Justin). Quan điểm của tôi là nói rằng JTA có giá trị ngay cả khi bạn không sử dụng giao dịch XA.