영속성 컨텍스트를 잘 디버깅하려면 이런거 보셈

[딱국(kgm12345)]

여기서 지금 두번째 출력이랑 세번째 출력 다르지?

이거 이해해야함

JPA가 영속성컨텍스트를 초기값으로 항상 유지시킨다는거고

이게 트랜잭션 단위에서 이루어지는게 아니라

JPA 자체적인 기능이라

DB쪽 레이어랑

JPA쪽 레이어

분리해서 제대로 디버깅 해야함

동시성 고려하면서 여러가지 테스트해보다

JPA이거로 동시성 고려하려면 기본기 탄탄해야한다고 느꼈음

[프갤러1(14.39)]

존나 어렵다 시발..

[나트륨찡(natriummi)]

천재노 이기 이기 ㅇㅅㅇ

[딱국(kgm12345)]

아 증명한답시고 findAll로 0번째 항목 가져온게 기존의 엔티티랑 동일하다는거 보여줬어야했는데 믿으셈 세번째 쿼리로 가져온 대상이랑 첫번째 쿼리로 가져온 엔티티랑 동일하고 마지막에 serr( a == b) 하면 트루 나옴

[딱국(kgm12345)]

이게 아마 find 를 했을때에는 어차피 쿼리 안날리고 영속성컨텍스트에서 직접 가져오니까 값이 갱신이 안된다는거를 인지하는건 뭐 네카라급은 기본으로 다 아는내용일텐데 3번쿼리를 일부러 벌크성으로 가져온거임. 얘가 이러면 새로운 정보를 폐기하는거임

[딱국(kgm12345)]

참고로 Test Entity 에서 Fetch Type Eager임

[딱국(kgm12345)]

LAZY면, 프록시니까 어차피 나중에 가져올때 쿼리 안날렸겠지 라고 하겠지만 EAGER인데도 이런거 물론 직접 조인으로 가져와봐야 정확한거긴 하겠지만 그정도까진 실험 안해볼래

[딱국(kgm12345)]

굳이 join으로 안하고 내가 왜 연관관계로 굳이 가져왔는지 후회가 돼서 memberRepository.findAll() 로 바꿨음. 여전히 똑같은 결과임

[딱국(kgm12345)]

이거 근데 딱보니까 일반 네카라급은 엔티티 원래있는거 그냥 쓰잖아! 하고 걍 쉬운거라고 하겠네. 쿼리문을 생각하자... 캐쉬라는건 원래 효율성을 위해 쓰는거잖아 근데 JPA는 효율성 위에 Read Repeatable 구현이라는 또다른 목표가 들어있고 이게 불완전하니까 항상 염두에 둬야함. 왜 불안전하냐? where절에서 데이터쓸때는 read committed라고

[딱국(kgm12345)]

즉, JPA를 Read Committed위에서 쓴다면 (그게 국룰임) 두가지 다른 격리수준을 매번 이때는 어떤 격리고 어쩌고 이런걸 다 따져야한다는거임. 쉽게 생각하면 데이터는 read committed, 엔티티에서 가져올때는 read repeatable임

[딱국(kgm12345)]

더 효율적으로 데이터를 갱신할 수 있는데 일부러 안한건 캐쉬의 영역이 아님. 당연한게 아님 이거. Read Committed에 맞춰서 엔티티를 갱신할수있을때 갱신하도록 설계했으면 그 규칙대로 코딩해야하는거겠지. 뭐 나도 엔티티는 Read Repeatable로 통일시키는게 더 편하다고 생각하긴 함