이전 청크의 ItemProcessor에서 엔티티를 수정한게 왜 문제인지 이해가 안간다. ItemProcessor에서 데이터를 수정하고 ItemWriter에서 DB에 flush를 할것 같은데 왜 다음 chunk에서 ItemReader에서 doReadPage()로 데이터를 읽는 시점에 의도치 않게 DB에 변경사항이 발생하는가?? 이미 앞선 데이터는 DB에 모두 반영되지 않았는가?? 이전 청크라는 상황이 이해 안된다. 이것이 왜 위험한가? 만약 이전 청크의 ItemProcessor에서 엔티티를 수정했다면? doReadPage()에서 데이터를 읽으려는 시점에 의도치 않게 DB에 변경사항이 반영될 수 있다. 이는 ItemReader의 책임 범위를 완전히 벗어난 동작이다. ItemReader는 데이터를 읽기만 해야 하는데, 실제로는 데이터 변경까지 일으킬 수 있는 것이다. 더 큰 문제는 이런 동작을 코드를 자세히 들여다보지 않으면 전혀 예상할 수 없다는 점이다.
배치 처리, 시스템 종결의 서막 💀 장에서 중복된 문장 발견. 두 세계의 공존 웹은 실시간 상호작용의 최전선에서 사용자와 연결을 담당한다. 배치는 시스템의 후방에서 대규모 데이터 처리를 책임진다. 둘은 역할이 다르지만, 함께 작동할 때 시스템은 완벽해진다. 함께 작동할 때 시스템은 완벽해진다. 배치가 없다면 시스템의 무게를 견딜 수 없고, 웹이 없다면 사용자와의 연결이 끊어진다. 네가 이 두 세계를 모두 이해하고 다룰 수 있다면, 시스템의 모든 것을 지배할 수 있다.
아래 설명에서 실무에서 어쩔 수 없이 실시간으로 변경된 데이터셋에 배치 처리를 한 사례를 알고싶다. "잠깐! 킬구형, JpaPagingItemReader의 문제가 아니라 실시간 데이터셋에 배치를 돌리는게 잘못된거 아냐?” 이상적으로는 맞는 말이다. 배치는 보통고정된 입력 데이터셋을 대상 으로 사용하는 것이 맞다. 하지만 실무에서는 어쩔 수 없이 실시간으로 변경되는 데이터셋에 대해서도 배치 처리를 해줘야 할 때가 있다. 이럴 때는 offset 기반 페이징 은 사용하지 않도록 하자.
킬구형 안녕, Fault Tolerant 쪽에서, retryLimit()을 설명해줄 때 만약 retryLimit 값이 3일경우, "첫번째 호출시도 1번, 재시도 호출 2번"으로 총 3번이 호출된다고 했잖아. 재시도 횟수는 항상 retryLimit - 1 이라 그랬고. 근데 왜 "ItemProcessor의 예외 발생 시 재시도 - 아이템 단위로 재시도 관리"의 마지막 호출 결과 찍어준 부분에서, retryLimit()은 3인데 왜 ItemProcessor는 4번이 호출되는거야? 위에 설명한대로라면 3번만 호출되어야 하는거 아냐?
멀티 스레딩에서 파일에 write할 때 질문이 있습니다. thread가 chunk 단위로 파일에 입력되는것은 확인했습니다. 그런데 결과 값의 정렬은 불가능한가요???? 예를 들어 db에 1, 2, 3, 4, 5 ... 라는 데이터가 있고 FlatFileItemWriter로 파일에 쓸 경우 1,2,3,4,5 이런식으로 정렬된 값이 저장 가능한지
humanThreatDataReader는 스레드 안전한 JpaPagingItemReader 를 사용했다. 라는 구문에서 헷갈리는게 있는데 JpaPagingItemReader의 경우는 lock을 걸지 않는데 SynchronizedItemStreamReader 데코레이터를 적용해야하지 않나요???
상태(State): 작전 수행 지점들 상태(State)란 Flow 내에서 현재 실행이 머무르거나 도달할 수 있는 모든 논리적 지점 을 의미한다. 자동문의 "문 닫힘/문 열림" 에 해당한다. Flow를 구성하는 상태(State)는 크게 두 가지 주요 유형으로 분류할 수 있다. 실행 상태 (StepState 등): 실행 상태는 Flow 내에서 실제 특정 작업(로직)을 수행하는 지점을 나타낸다. 우리 강의의 예제 코드에서 사용된 analyzeContentStep , publishLectureStep , summarizeFailureStep 과 같은 Step이 대표적인 실행 상태(StepState)에 해당한다. 종료 상태 ( EndState ): 종료 상태는 Flow 실행의 최종 도착점을 나타내는 상태이다. Flow가 이 상태에 도달하면 더 이상 진행되지 않고 실행이 종료된다. Job의 최종 결과는 Flow가 어떤 EndState 로 끝났는지에 따라 결정된다. 다이어그램의 [작업 종료] 가 바로 이 종료 상태(EndState)를 가리킨다. 종료 상태(EndState): Flow 실행의 최종 도착점 이다. 이 상태에 도달하면 실행 흐름이 더 이상 진행되지 않고 Flow가 종료된다. Job의 최종 결과는 어떤 EndState로 끝났는지 에 따라 결정되며, 앞선 다이어그램의 [작업 종료] 가 바로 이 종료 상태(EndState)에 해당한다. 여기서 종료 상태가 두개인데 다른 내용인가요???
이 기본 구현에서 호출하는 getResultList() 는 전체 데이터를 메모리에 한 번에 로딩하므로 실제 스트리밍이 아니며 따라서 타 JPA 구현체 사용 시 주의가 필요하다. 라고 하셨는데 JpaCursorItemReader를 이용하면 모든 데이터를 메모리로 가져오기 때문에 OutOfMemoryError가 날 수 있나요?? 추가로 실무에서는 쿼리가 복잡할텐데 JPA 보단 JDBC를 사용하는 편인가요???
킬구형 일부러 그런건진 모르겠는데, 우선은 Batch Listener 섹션에서 실행명령에 전부 --job.name=~~ 형식으로 되어있어. 잡이름을 인식 못해서 Job Bean이 여러개 명시되어있으면 실행할때 오류나는 것 같아. --spring.batch.job.name= 처럼 안하면 안될 것 같은데, 이건 의도적으로 줄인걸까?
한다 제보를 KILL-9, 바란다 응답 [제보 정보 수집중... 🤖 ] [KILL-9@user]$ cd 커리큘럼/섹션4/3장/작전1 해킹 주문 데이터베이스 정찰 작전에서 프락치를 발견했다 JdbcPagingItemReader 가 whereClause에 거짓 증거를 제출해서 혼란을 야기했다 status = 'READY_FOR_SHIPMENT' 이고 not null 이어햐 하지 않을까 생각한다 CANCELLED 가 아닌 것 같다 다시 보니 작전에 혼동이 있는 것 같다 확인요망 🔥 유해 게시물 처형 작전 시스템에도 버그가 발견됐다 전체코드에서 JpaCursorItemReader 에 queryString 조건이 잘못된 것 같다 이후의 예시 코드들은 잘돼있지만 전체코드 복사하는 녀석들이 많기 때문에 처리부탁한다 [추가 처형 요청... 💀 ] [KILL-9@user]$ cd 커리큘럼/섹션3/2장/작전1 글 쓰는 김에 한 녀석도 추가 제보하겠다 FlatFileItemReader 고정길이 예제도 처형 부탁한다 소제목인 .columns() 예제 이미지가 정확하다 하지만 예시코드라고 적혀있는 Range는 틀렸다 이것은 KILL-9 후보생의 혼란만 가중시킬뿐이다
웹/배치 리소스 사용 부분에서 배치는 필요 할 때만 실행이된다고 했는데 예전에 공공API를 한번 호출 할 때 오래 걸렸던걸로 기억이 난다. 외부API를 1번 호출 할 때 10개씩 가져오는데 약 1분이 걸린다면 1년치 데이터(약 40만건)을 적재를 했어야했다. AWS를 잘 모르지만 람다에서 함수 호출 1번 할 때 최대 15분이라 한번 배치를 돌려서 40만건을 쌓을려면 람다를 도입하기 힘들다고 판단했다. 필요 할 때만 이용하는 람다가 이점이긴하지만 1년치 데이터를 쌓는 부분에서 고민이된다. 아니면 람다를 반복 호출하는게 맞는지... 공공API 1번 호출 할 때 데이터 10건이라 데이터 약 40만건 쌓을려면 4만번 호출한다. 그래서 EC2를 도입했었는데, 1년치만 쌓을 때 EC2를 쓰고 그 이후에는 람다를 도입하는게 맞을지 궁금하다. (반말 죄송합니다ㅠㅠ)
