XA 트랜잭션의 데이터 일관성

XA 트랜잭션의 데이터 일관성

데이터베이스(예: Oracle)와 JMS 제공자(예: HornetQ)가 XA 트랜잭션에 참여하고 있다고 가정합니다.메시지는 JMS 대기열로 전송되고 일부 데이터는 동일한 분산 트랜잭션의 데이터베이스에 지속됩니다.트랜잭션이 커밋된 후 메시지 소비자는 지속적인 데이터를 읽고 별도의 트랜잭션으로 처리합니다.

첫 번째 XA 트랜잭션과 관련하여 트랜잭션 관리자(예: JBoss)는 다음과 같은 일련의 이벤트를 실행할 수 있습니다.

1. 준비(호넷Q)
2. 준비(오라클)
3. 커밋(호넷Q)
4. 커밋(Oracle)

HornetQ에서 커밋이 완료된 후 소비자가 데이터를 읽기 시작하지만 Oracle에서 계속 실행되면 어떻게 됩니까?소비자가 오래된 데이터를 읽습니까?

이 질문은 XA 트랜잭션에 참여하는 모든 종류의 여러 리소스로 일반화될 수 있습니다. 즉, 다른 동시 트랜잭션의 판독기가 (한 리소스에서 커밋된 데이터를 읽고 다른 리소스에서 오래된 데이터를 읽음으로써) 일관성 없는 상태를 얻을 수 있는 작은 시간 창(커밋 단계가 실행될 때)의 가능성이 있습니까?

트랜잭션 리소스가 이를 방지하는 유일한 방법은 커밋이 발행될 때까지 준비 단계가 완료되면 영향을 받는 데이터의 모든 리더를 차단하는 것이라고 생각합니다.이렇게 하면 위에서 언급한 예제 메시지 소비자는 데이터가 데이터베이스에 커밋될 때까지 차단됩니다.

안타깝게도 XA 트랜잭션은 일관성을 지원하지 않습니다.CAP 정리에 매핑되면 XA는 여러 데이터스토어 간의 가용성 및 파티션 허용 시간을 해결합니다.그렇게 함으로써 일관성을 희생해야 합니다.XA를 사용할 때는 궁극적으로 일관성을 유지해야 합니다.

어떤 경우에도 CP 또는 AP 시스템을 생성하는 것은 데이터스토어 또는 트랜잭션 모델에 관계없이 이 문제에 직면할 수 있습니다.

저는 Weblogic JMS와 Oracle 11g를 기반으로 약간의 다른 환경에 대한 경험이 있습니다.이 답변에서 저는 그것이 정확히 똑같이 작동하고 있다고 생각합니다.제 대답이 당신에게 도움이 되기를 바랍니다.

우리의 경우에는 로컬 시스템 내에서 발생하는 다양한 이벤트를 기반으로 통지해야 하는 "원격" 시스템이 있었습니다.다른 시스템도 우리의 데이터베이스에 빨간색으로 표시되어 사용 사례가 당신의 문제와 거의 동일하게 보입니다.사건의 순서는 당신의 것과 정확하게 똑같았습니다.테스트 시스템에는 단 한 건의 오류도 없었습니다.모두가 그것이 효과가 있을 것이라고 생각했지만, 우리 중 일부는 그것이 올바른 해결책인지 의심했습니다.소프트웨어가 운영 환경에 영향을 미치면서 일부 BPM 프로세스가 예측할 수 없이 실행됩니다.그래서 질문에 대한 간단한 대답: 네, 가능하고 모든 사람들이 그것을 알고 있어야 합니다.

우리의 해결책은 잘 계획된 해결책은 아니었지만, 두 커밋 사이의 짧은 시간 창이 시스템에 제동을 걸고 있다는 것을 인식했기 때문에 대기열에 "지연"을 추가했습니다(1-2분 정도였던 것으로 기억하면).다른 커밋을 완료하고 일관된 데이터를 읽기에 충분했습니다.나의 관점에서 그것은 최선의 해결책이 아닙니다.동기화 문제를 해결하지 못하고 있습니다(오라클 트랜잭션이 1-2분보다 길면 어떻게 됩니까?).

여기 읽을 가치가 있는 훌륭한 블로그 게시물이 있고 마지막 해결책이 제게는 최고로 보입니다.우리는 그것을 다른 시스템에 구현했고 그것은 훨씬 더 잘 작동하고 있습니다.스레드가 "고정"되지 않도록 재시도(재읽기)를 제한해야 합니다(일부 오류 보고 포함).이 제한으로 인해 저는 지금까지 더 나은 해결책을 찾을 수 없었습니다. 따라서 누군가 더 나은 선택권을 가지고 있다면 저는 그것을 듣기를 고대하고 있습니다.:)

편집: 오타.

예. 트랜잭션이 실패하고 이후에 롤백되더라도 DB가 실제로 커밋하기 전에 외부 시스템이 사용자가 보낸 메시지를 수신하고 사용할 수 있습니다.

지난 2년 동안 저는 WebSphere MQ를 JMS 공급자로, Oracle 11g을 백업 DB로 사용하여 XA 트랜잭션을 사용하여 분산 시스템의 유지보수 및 개발을 수행해 왔습니다.
배치 작업 중 하나는 DB에서 오프라인 메시지를 읽고 JMS로 보낸 다음 DB에서 전송된 메시지로 표시합니다. 이는 모두 동일한 XA 트랜잭션의 일부입니다.메시지 또는 DB가 실패하면 트랜잭션이 롤백됩니다.

경우에 따라 메시지가 JMS에 대해 너무 커서 send()가 실패하고 전체 트랜잭션이 롤백()되어 DB가 변경되지 않은 상태로 유지될 수 있습니다.
그러나 외부 소비자는 롤백 전에 전송된 모든 메시지를 여전히 수신하고 처리하고 있었습니다.처리된 모든 메시지에 대해 전자 메일을 보낼 것이기 때문에 알고 있었고, DB에 전송된 것으로 표시되지 않은 메시지에 대한 전자 메일을 많이 받았습니다(거래가 롤백되었기 때문에).

이 외부 시스템이 내 시스템에서 보낸 메시지 수를 COUNT(*)로 선택하려면 이미 수백 개의 메시지를 사용했음에도 불구하고 0개의 메시지를 읽습니다.

따라서 XA 트랜잭션을 사용하는 경우에도 외부 시스템에서 오래된 데이터를 읽을 수 있습니다.

상태 필드를 삽입하므로 각 단계가 완료되면 상태가 업데이트되고, 작업을 수행하기 전에 판독기에서 상태를 확인해야 합니다.

언급URL : https://stackoverflow.com/questions/37709869/data-consistency-in-xa-transactions