WW41 ~ WW42

241007

- 실제 코드로 카프카 보내보고 throw 시 못가는것도 확인하기
- 레디스 코드리뷰 받은 거 수정하기
- 레디스 AOF 적용하기 

 

 

241008

- 레디스 코드리뷰 수정 중 (레디스 어노테이션 위치 adaptor로, computePrefixWith로 key 규칙 변경)
ㄴ 레디스 어노테이션을 서비스에서 adaptor로 옮기면서 다시 에러 발생
(Could not write JSON: Java 8 date/time type `java.time.LocalDateTime` not supported by default)



카프카 정리 잘 해놓음
https://m.blog.naver.com/fbfbf1/223100304313

 

241014

- 레디스 역직렬화/직렬화 미루고
- 다시 ftp 감지 코드 다른 장비 작성 중 (전략 패턴 적용)

 

241015

 

 


< 전략패턴 >
- ContextService(인터페이스) <-구현- ContextServiceImpl(클래스) : 컨트롤러나 리스너에서 contextService 불러서 클래스 조건에 따라 가져오게 

(즉, ContextServiceImpl에서는 Strategy를 전역 변수로 두고, 메서드에 따라 다른 전략 가져오게)

-> 단, 메서드에 따라 다른 전략 가져올 수 있게 StratagyServiceFactory를 두어서 알맞은 클래스 return 되게

-> 이후 공통 코드는 모두 ContextServiceImpl에 놓고

전략적으로 사용할 코드는 불러온 전략서비스에서 메서드로 각각 알맞게 사용하기

 

- Strategy(interface) <-구현- A_Strategy(class), B_Strategy(class)

 

241016

- 전략패턴 적용 및 중복 코드 제거 (contextService 사용)

 

241017

< @Transactional(readOnly = true) 사용하는 이유 >

-> 성능상 이점!
ㄴ 이유 : JPA의 영속성 컨텍스트가 수행하는 변경 감지(Dirty Checking)와 관련이 있음

설명)
영속성 컨텍스트는 Entity 조회 시 초기 상태에 대한 Snapshot을 저장함

트랜잭션이 Commit 될 때, 초기 상태의 정보를 가지는 Snapshot과 Entity의 상태를 비교하여 변경된 내용에 대해 update query를 생성해 쓰기 지연 저장소에 저장함

일괄적으로 쓰기 지연 저장소에 저장되어 있는 SQL query를 flush 하고 데이터베이스의 트랜잭션을 Commit 함으로써 우리가 update와 같은 메서드를 사용하지 않고도 Entity의 수정이 이루어짐 => 변경 감지(Dirty Checking) 

readOnly = true를 설정하게 되면 스프링 프레임워크는 JPA의 세션 플러시 모드를 MANUAL로 설정한다.
( * MANUAL 모드는 트랜잭션 내에서 사용자가 수동으로 flush를 호출하지 않으면 flush가 자동으로 수행되지 않는 모드 )

즉, 트랜잭션 내에서 강제로 flush()를 호출하지 않는 한, 수정 내역에 대해 DB에 적용되지 않음!!
이로 인해 트랜잭션 Commit 시 영속성 컨텍스트가 자동으로 flush 되지 않으므로 조회용으로 가져온 Entity의 예상치 못한 수정을 방지!
또한, readOnly = true를 설정하게 되면 JPA는 해당 트랜잭션 내에서 조회하는 Entity는 조회용임을 인식하고 변경 감지를 위한 Snapshot을 따로 보관하지 않으므로 메모리가 절약되는 성능상 이점도 존재!