작성자 없음
작성자 정보가 삭제된 글입니다.
작성
·
77
1
humanThreatDataReader는 스레드 안전한 JpaPagingItemReader를 사용했다.
라는 구문에서 헷갈리는게 있는데 JpaPagingItemReader의 경우는 lock을 걸지 않는데 SynchronizedItemStreamReader 데코레이터를 적용해야하지 않나요???
답변 2
1
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
[SYSTEM INVESTIGATION INITIATED]
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
[KILL-9]: "lock을 걸지 않는다라... 확인해볼까? 💀 "
**TARGET ACQUIRED: JpaPagingItemReader**
훌륭한 질문이다! 하지만 놈이 숨기고 있는 진실을 파헤쳐보자.
JpaPagingItemReader는 페이지 읽기에 직접적으로 lock을 사용하지 않는다. 하지만...
** 부모 클래스 AbstractPagingItemReader의 doRead() 코드를 보자:(6장 작전1에서 설명했듯이 JdbcPagingItemReader도 이녀석을 상속했었지.)**
```java
@Nullable
@Override
protected T doRead() throws Exception {
this.lock.lock(); // ← 이놈이다! ReentrantLock 발견!
try {
if (results == null || current >= pageSize) {
if (logger.isDebugEnabled()) {
logger.debug("Reading page " + getPage());
}
doReadPage(); // JpaPagingItemReader#doReadPage() 호출
page++;
if (current >= pageSize) {
current = 0;
}
}
int next = current++;
if (next < results.size()) {
return results.get(next);
}
else {
return null;
}
}
finally {
this.lock.unlock(); // ← 여기서 ReentrantLock 해제!
}
}
💀 결론: JpaPagingItemReader는 데이터 읽기 측면에서 Thread-Safe하다! 부모 클래스에서 ReentrantLock으로 동기화를 보장하고 있기 때문에 SynchronizedItemStreamReader 데코레이터가 불필요하다.
💀 P.S: 혹시나 하고 예제를 다시 살펴보니 saveState가 false로 잘 설정되어있구나.
6장 작전1에서 설명한 스프링 배치의 두 가지 측면에서의 스레드 안정성 모두를 만족했다.
[THREAD SAFETY: CONFIRMED]
-1
안녕하세요, 인프런 AI 인턴입니다.
이동연님, JpaPagingItemReader의 스레드 안전성과 관련된 좋은 질문을 주셨습니다. 일반적으로, JpaPagingItemReader는 스레드 안전하지 않기 때문에 멀티스레딩으로 사용할 경우 문제가 생길 수 있습니다. 이를 해결하기 위해 SynchronizedItemStreamReader와 같은 데코레이터를 사용하여 스레드 안전성을 보장하는 방식을 사용할 수 있습니다.
이와 관련해, 기존에 유사한 질문을 다룬 게시물이 있으니 참고하시면 도움이 될 것입니다:
이 답변이 도움이 되셨기를 바라며, 추가적인 질문이 있으시면 언제든지 질문해 주세요.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.