Java EE : JTA를 직접 사용하는 이유는 무엇입니까?

Question

저는 JTA를 이해하려고 노력 중이며 Bitronix를 트랜잭션 관리자로 선택하고 있습니다 (학습 및 이해를 위해서). 나는 Bitronix reference guide here 내부의 코드를보고 있으며 자신에게 궁금한 점이있다. JDBC (자체적으로 트랜잭션 (Connection)를 롤백 할 수 있음)를 사용하고 있다면 왜 그런 코드를 작성하고 싶습니까? !?!

이제 코드 스 니펫의 핵심은 기존 트랜잭션 데이터 저장소보다 Bitronix/JTA를 사용하는 방법을 간단히 보여 주지만 어쨌든 여전히 고유 한 이점을 얻지 못합니다. "당신이 사용하는 유일한 주 데이터 소스가 데이터베이스와 메시지 중개자이고 JDBC/JMS를 사용하여 각각 통신하고이 두 표준 (JDBC/JMS)을 사용하는 경우, 이미 트랜잭션 적이기 때문에 왜 JTA를 사용해야합니까?!?! "

JTA는 JDBC, JPA, JMS 등의"내부 "Java EE API 일종입니까? 그것으로 미친 짓을하고 싶은 1 % 놈들을 위해 공개적으로 노출 된 것일까 요? 아니면 JTA의 아이디어/적용 가능성을 놓치고 있습니까?

JTA를 직접 타격하기 위해 JDBC가 아닌 JMS와 JMS가 아닌 두 가지 사용 사례를 생각할 수는 있지만 JTA는 처음부터 퍼지기 때문에 이러한 경우가 오프 트랙인지 아닌지 전혀 알지 못합니다 :

• 아마도 응용 프로그램에 복잡한 I/O 시스템이 있고 디스크의 동일한 파일에서 읽고 쓰는 여러 스레드가있을 수 있습니다. 아마도 각 스레드가 트랜잭션을 사용하여이 파일에 쓸 수 있습니다. (예?!? 아니오!!?)
• 아마도 시스템의 상태를 나타내는 상태 시스템 POJO가 있으며 여러 스레드가 시스템을 수정할 수 있습니다. 아마도 각 스레드가 트랜잭션을 사용하여 시스템의 상태를 변경하게 할 수 있습니다.

내 질문의 루트 추측이다 (예 아니오?!?!?) : 내 JPA (최대 절전 모드) 및/또는 JDBC 호출이 이미 트랜잭션 경우

• , 왜 것 JTA begin-> commit/rollback 블록 안에 그들을 감싸고 싶습니까? JMS 및 메시징 시스템 용.
• JPA/JDBC/JMS 외에도 JTA를 사용하여 일련의 작업을 처리하는 유스 케이스는 무엇입니까?

미리 감사드립니다.

Answer 1

오픈 트랜잭션을 롤백하는 것 이상으로 JTA는 제공자가 구현할 수있는 XAResource 인터페이스를 제공하므로 JDBC 드라이버와 JMS 제공자는 이미이를 수행하고 사용자가 직접 구현할 수 있습니다. 이것은 개방형 표준을 기반으로하며 아마도 읽을 가치가 있습니다.

왜 우리는 이것을 원했습니까?

재해에 매튜스의 예를 생각해

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 *** 

는 불행하게도 JMS 메시지는이 분산 트랜잭션을 가진 아주 진짜 문제이며, 다른 은행에 갔다.

는 XA으로이 시나리오가 밖으로 재생됩니다 방법입니다

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. 

지금 당신은 전원 플러그가 DB의 최종 커밋 동안 꺼내되는 경우 발생하는 요청할 수 있습니다. JMS 대기열은 커밋 된 것이지만 XA 트랜잭션은 DB를 다시 사용할 수있을 때까지 열린 상태로 유지되고 다시 DB를 커밋하도록 지시합니다 (DB는 커밋 할 수 있음을 약속하고 이것이 XA 준수의 일부입니다).).

JTA에 대해 정말 멋진 점은 자신 만의 XAResource를 쉽게 구현하고이 훌륭한 프레임 워크에 묶을 수 있다는 것입니다!

1. 사용자 정의 상태이거나에서 최종 코드 블록이 될 수 없습니다 파일 :

   UPDATE

   그래서 당신은 다음과 같은 자신을 요청할 수 있습니다 사용자 정의 트랜잭션을 구현하는 경우에 대한 귀하의 질문에 대답하기 거래 범위?

2. 외부 시스템 (예 : DB 또는 JMS)에서 사용자 정의 상태/파일을 되돌릴 필요가 있습니까?
3. 외부 시스템에 대한 간단한 getRollbackOnly() & setRollbackOnly()는 사용자 정의 코드에 대한 보상 처리 (즉, 사용자 정의 상태/파일 되돌리기)가 불충분합니까?

모두 1에 대한 대답, 2 & 3 YES 그때는 아마 사용자 정의의 XAResource를 원하는 경우, 그렇지 않으면 나는 그것이 아마 잔인한 생각합니다.

그러나 코드가 비즈니스 로직에서 Java EE 공간에 참여할 프레임 워크 또는 라이브러리 인 경우 XAResource를 구현할 수 있습니다!

Answer 2

데이터베이스와 메시지 서비스를 모두 처리하는 트랜잭션을 가질 수 있습니다. 나는 JTA없이 그렇게 할 수있는 방법을 모른다.

간단한 개념 예.정확한 코드는 중요하지 않습니다 :

추가 데이터베이스에 고객 번호 345에 대한없이 accountBalance $ (100) 이하 JTA 트랜잭션

설정을 시작 JMS 메시지 "OtherBank 계정 번호 987로 전송 $ (100)"

을 큐에

OtherBank는 별도의 은행 인 JTA 트랜잭션을 커밋, 우리는 당신이 O를와 통신 가정 ver JMS.

시작 트랜잭션 및 커밋은 JTA에서 처리합니다. 대기열에 추가하는 데 실패하면 철회도 자동으로 롤백됩니다.

실생활은 그리 간단하지 않지만 아이디어가 있어야합니다.

편집 :

JTA는 시스템의 시간 부분이 제대로 XAResource을 구현할 수 있습니다 사용할 수 있습니다. 이를 구현하면 리소스가 분산 트랜잭션에 참여할 수 있습니다. 언뜻보기에 두 제안 된 예제 모두 XAResource을 구현할 수 있습니다.

"앱에 복잡한 I/O 시스템이 있고 디스크의 동일한 파일에서 여러 스레드 읽기/쓰기가 있습니다." - 생각하면 데이타베이스처럼 들릴 수 있습니다.

"시스템의 상태를 나타내는 상태 기계 POJO가 있고, 여러 스레드가 기계를 수정할 수 있습니다." - 변화가 충분히 격리 될 수 있다면 이것은 분명히 후보자가 될 수 있습니다.

루 브릭의 첫 부분은 기본적으로 리소스가 논리적으로는 일 수 있다고 생각합니다.은 XAResource입니다. 즉, ACID의 개념은 의미가 있습니다. 두 번째는 해당 인터페이스를 구현하는 것이 가능하고 가치가 있다는 것입니다 (아직 구현되지 않은 인터페이스).

Answer 3

제 생각에는 첫 번째 고려 사항은 TX 관리자와 TX 시스템을 꾸미는 것입니다.

응용 프로그램을 디자인 할 때 Transactional이라는 단어는 ACID에 대한 의도를 표시합니다. 이것이 비즈니스 요구에 의해 주도되어야하므로 비즈니스 코드에이 의도를 넣고 싶습니다.

뭔가 마법 (실제 생활에서 내 컨테이너) 기본 TX 시스템 (데이터베이스, JMS 브로커 등) 또한

을 따라 올바르게 내 텍사스의 의도를 짜는 것으로 예상, JTA 통합을 허용하는 SOMES 인터페이스를 정의 기존의 JTA 시스템과 새로운 (궁극적으로는 새로운, 이국적인) TX 시스템 사이에서. 예 : GigaSpaces XAP은 메모리 내 DataGrid입니다. 그것은 SQL이 아닌 JMS가 아니지만 이것을 it provides a JTA integration으로 쉽게 처리 할 수 ​​있습니다. 우리는 다른 많은 제품을 인용 할 수 있습니다 ...

분명히 킬러 예제는 서로 다른 시스템 간의 XA 트랜잭션을 지원합니다 (저스틴을 가리킴). 제 말은 JTA가 XA 트랜잭션을 사용하지 않아도 JTA가 가치 있다고 말합니다.