giao dịch Arjuna JTA rollbacked bất ngờ

Question

Khi tôi kiểm tra JBoss logs Tôi thấy rất nhiều những lỗi

2012-03-29 12:01:27,358 WARN @ [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource < 131075, 32, 30, 1--53e2af7c:eff6:4ec11bf7:2e1da4-53e2af7c:eff6:4ec11bf7:2e263d                 > 
2012-03-29 12:01:27,398 WARN @ [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource < 131075, 31, 29, 1--53e2af7c:d397:4e8c1b0e:25b6d-53e2af7c:d397:4e8c1b0e:29d09                  > 

Sau đó, khi tôi cố gắng gửi một thông điệp JMS tôi thấy lỗi này:

2012-03-29 12:02:43,778 WARN @ [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.opcerror] [com.arjuna.ats.internal.jta.resources.arjunacore.opcerror] XAResourceRecord.commit_one_phase caught: java.lang.IllegalMonitorStateException 
2012-03-29 12:02:43,778 WARN @ [org.springframework.jms.listener.DefaultMessageListenerContainer] Setup of JMS message listener invoker failed for destination 'queue/request' - trying to recover. Cause: JTA transaction unexpectedly rolled back (maybe due to a timeout); nested exception is javax.transaction.RollbackException: [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Can't commit because the transaction is in aborted state 

tôi nghi ngờ rollback là hậu quả của lỗi trước đó. Tôi có đúng không? điều gì có thể khiến giao dịch vẫn ở trạng thái hủy bỏ như thế này?

tìm kiếm xung quanh Tôi đã tìm thấy bài đăng này: What causes Arjuna 1603 (Could not find new XAResource to use for recovering non-serializable XAResource) . Tôi hiểu rằng một số nhật ký giao dịch đã được lưu giữ nhưng điều này không giải thích cách khắc phục sự cố hiện tại của tôi.

Answer 1

Tôi đã thấy lỗi tương tự trên JBoss 5.1 (ít nhất là một trong những thứ hai trong đó đề cập đến một thời gian chờ)

Chúng tôi không tìm ra nguyên nhân thực tế nhưng nó là rất có khả năng rằng nó được gây ra do một giao dịch dài chạy bị "gặt hái"

Lý do chúng tôi đưa ra kết luận này là chúng tôi thấy điều này vào thời điểm tải cao và một số hoạt động đã mất nhiều thời gian để hoàn thành.

Chúng tôi sử dụng PostgreSQL và có rất nhiều kết nối "đang chờ giao dịch" được xóa sau khi gặt hái. Kiểm tra thời gian chờ giao dịch trong cấu hình của bạn và đặt giá trị đó thành giá trị cao hơn để xem liệu nó có làm giảm bớt sự cố hay không.

https://community.jboss.org/wiki/TransactionTimeout bao gồm cách quản lý cài đặt này.

Answer 2

Nói chung, mọi RuntimeException được ném từ một quản lý được (một cái gì đó được tiêm với gói JBoss proxy) và không được đánh dấu là @ApplicationException (rollback = false) sẽ làm cho giao dịch quay trở lại.

Những trường hợp này thường rất dễ thấy trong tệp nhật ký.

Thời gian chờ mặt khác, hơi phức tạp hơn một chút. bạn sẽ thấy trong tệp nhật ký một cái gì đó như: "Hủy bỏ hành động id -3f57fd2d: e48e: 4cf8de0f: bc được gọi trong khi nhiều chuỗi hoạt động bên trong nó."

Các cuộc gọi khác sẽ tiếp tục chạy và sẽ không thành công khi họ cố truy cập kết nối cơ sở dữ liệu, nhận được ngoại lệ "giao dịch được đánh dấu để quay lại".

Answer 3

Chúng tôi đã nhận được một lỗi tương tự và sau đó phát hiện ra rằng nguyên nhân phải liên quan đến cách chúng tôi tạo và xử lý các thực thể của chúng tôi. Chúng tôi đã có một đối tượng cha mẹ với một danh sách các thực thể trẻ em và chúng tôi đã tạo ra các bản sao của cha mẹ và sau đó cố gắng để thêm trẻ em mới vào danh sách. Vấn đề mặc dù là những danh sách con đã được đánh dấu với việc bốc chú thích lười biếng:.

@OneToMany (cascade = CascadeType.ALL, lấy = FetchType.LAZY ...

nhưng lại gây ngủ đông để thất bại Để khắc phục nó chúng tôi đã đuổi cuộc gọi trên thực thể để Hibernate sẽ ngừng cố gắng để lấy các trẻ em bất cứ khi nào chúng tôi tạo ra các bản sao của mẹ.

((Session) entityManager.getDelegate()). đuổi (thực thể để đuổi)

Đây có thể không phải là giải pháp cho vấn đề cụ thể của bạn, nhưng hy vọng nó sẽ giúp một ai đó!

Answer 4

Chúng tôi giải quyết vấn đề tăng max_prepared_transactions thành 100 trong tệp postgresql.conf.