오늘은 심심풀이 겸
JTA를 공부하려고 하는데요
진짜 대~규모의 서비스를 하면 이런상황이 뭔가 나오지 않을까? 라는 막연함을 동기로 삼아
JTA를 공부해 보려고합니다.
엄청난 심화과정은 나중에 할 예정이고 오늘은 이론정도만 공부할 것 같네요
JTA
Java Transaction API 여러 데이터베이스의 트랜잭션을 제어하기 위한 인터페이스
JTA 구현체
- Atomikos
- Bitronix
- Narayana
구현체 전부 트랜잭션 내용을 기록하는 트랜잭션 로그 파일을 따로 생성합니다.
XA
전역 트랜잭션에서 여러 데이터베이스에 접근하기 위한 표준
XA의 특징은 2단계 단계를 거친 이후에 Commit이 일어나는데요.
- prepare
2개의 데이터베이스의 각각 변경사항을 반영할 수 있는 지 요청
만약 해당 단계에서 에러가 발생 시 롤백이 이루어집니다.
prepare 이전부터 해당 레코드에 lock이 걸리기 때문에
두 데이터베이스에 일관된 데이터를 보장합니다.
(둘 다 데이터가 없거나 둘 다 데이터가 있거나)
- commit
각 데이터베이스에 실제 Commit이 이루어집니다.
하지만..
그림만 봐도 알다시피 성능적인 측면으로는 애매할 것 같은데요...
일단 각각 DB 마다 lock거는 부분도 그렇고...
DB마다 통신이 이루어져야 하고....
통신은 둘째치고 lock 거는게 조금 크리티컬 하긴 하네요...
XA 표준 말고 Saga 패턴으로 구성할 수 있는지는 나중에 JTA를 실제로 쓰면 알아보든 직접 구현을 하든 해야겠네요 ㅋㅋㅋ
장점
트랜잭션 기능을 지원하는 인터페이스도 같이 사용할 수 있습니다.
예를들어 JMS(Java Messege Service) 와 Oracle DB를 같이 사용해 하나의 트랜잭션으로 묶어 작업을 할 수 있습니다.
위의 구성이 가능한 이유는
JTA 환경에서는 JtaTransactionManager 으로 트랜잭션을 관리를 하여
해당 트랜잭션 매니저가 두 개의 트랜잭션을 관리를 해주기 때문입니다.
또한 DB 연결 설정 부분만 JTA 환경에 맞춰 변경하면 비즈니스 로직은 크게 변경될 일이 없는 장점이 있습니다.
주의사항
각 DB 드라이버를 XA 표준에 맞추어져 있는 드라이버로 변경하여야 합니다. 따라서 해당 데이터베이스가 XA 표준에 맞춘 드라이버가 존재해야합니다.
느낀 점
아무리 생각해도 JTA는 거의 안쓰지 않을까? 뇌내망상을 해봅니다.
데이터베이스 종류가 다른 것들을 같이 사용하면서 나오는 이슈도 있을 것 같고
여러 데이터베이스에 한 트랜잭션으로 뭔가 처리하고 싶으면
차라리 EDA 구성해서 이벤트처리로 구성을 하던가 Kafka 같은 Amqp 메세지큐 쓰는게
훨씬 좋은 구성일 것 같습니다.
참고
