Spring Batch를 이렇게 사용해도 괜찮을까요?

Question

기존에 스케줄러로 동작하는 로직을 배치로 처리해보고 싶은 마음에 이래저래 생각하는 내용이 옳은 생각인지 여쭤보고싶어 이렇게 글을 적어봅니다.기존 스케줄러로 동작하던 로직은A 테이블의 데이터를 기반으로, B, C, D 테이블의 데이터를 갱신하는 로직입니다.A 테이블에서 아직 처리되지 않은 데이터를 구분하는 플래그 필드로 구분하고, 해당 데이터에 따라B, C, D의 특정 데이터를 update하고 마무리되면 A테이블의 플래그를 처리됨으로 변경한 뒤 마무리합니다.&#34;A 테이블의 미처리 데이터를 Reader로 읽은 뒤, Processor에서 연산 및 B, C, D 테이블 업데이트 후Writter에서 A 테이블의 플래그를 처리됨으로 변경하여 완료&#34; 하는 방법을 생각해봤고,각각의 B, C, D 테이블을 순차 처리하기 위해 CompositeItemProcessor를 사용하고,각 단계에서 update 쿼리를 수행하려고 했습니다.하지만 곰곰히 생각해보니, 배치의 용도는 읽은 데이터를(reader) 가공하여(processor) 업데이트한다(writer)가 아닌가? 라는 의문점이 생기면서, 그러면 Processor에서는 update나 insert 등의 작업은 수행하면 안되는건가?만약 배치 처리중에 장애가 나면 processor부분도 rollback이 될 수 있는건가? 하는 의문점이 들면서뭔가 배치를 써서 할 일이 아닌데, 배치를 괜히 써보려고 욕심부리는건가 라는 생각까지 왔습니다.CompositeItemProcessor를 사용해서, 여러 테이블과 트랜잭션하는 레퍼런스도 서칭능력이 부족한 것인지쉽게 찾을 수 없었구요..어쩌면 배치를 잘못 알고 쓰려고 하고 있는 것 같다 라는 생각이 확 들었습니다.혹시 저와 같은 케이스나 제가 생각하는 방식의 문제점을 짚어주실 선배님이 계실까요?

adduci · Answer

배치로 처리하는게 더 좋죠 그런 동작은ㅎㅎ우선 processor 단계에서 별도의 처리 작업이 필요 없으면 그냥 reader에서 전달받은 데이터 그대로 writer로 주면 됩니다Update는 writer에서 하면 되구요트랜잭션은 chunk 단위로 이루어지기 때문에 실패한 chunk 이전의 chunk들은 다 커밋되어 영속성을 가집니다

Spring Batch를 이렇게 사용해도 괜찮을까요?

1개의 답변

Q&A 목록