정리

정리

자 그래서 이제 이번 시간에 공부했던 것을 한번 정리해 보겠습니다.

이번 시간에는 정리를 할 건데, 지금까지 영속성 컨텍스트라는 것에 대해서 알아봤구요.

그 다음에 JPA에서 가장 중요한 것 두 가지, 맵핑하는 것과 영속성 컨텍스트.

하나는 정적인 맵핑 과정이고 하나는 실제 동작하는 메커니즘을 설명하는 거죠. 그래서 JPA의 가장 내부 구조랑, 내부가 동작하는 방식에 대해서 알아본 겁니다.

그 다음에 영속성 컨텍스트는 엔티티를 영구 저장하는 환경이라는 뜻이라는 거고요.

그 다음에 사실 이 영속성 컨텍스트는 눈에 보이는 개념이 아니에요. 대신에 엔티티 매니저를 통해서 영속성 컨텍스트에 접근하는데,

지금 우리가 일반적으로 쓰는 환경에서는 엔티티 매니저를 생성하면 그 안에 영속성 컨텍스트가 있다 라고 보시면 됩니다. 사실상 우리가 말했던 1차 캐시라는 게 영속성 컨텍스트라고 보시면 됩니다.

그리고 나중에 스프링 프레임워크랑 같이 할 건데, 그때가 되면 이게 조금 개념이 달라집니다. 그거는 이제 그때가서 다시 설명을 드릴게요.

그리고 엔티티는 생명 주기가 있고,

이건 그림 한번 보세요.

자 비영속 상태는 아무것도 아닌 거.

영속 상태는 persist()해서 집어넣은 상태, 아니면 em.find()로 가져온 상태를 말하고요.

그 다음에 이제 준영속 상태는 이제 영속성 컨텍스트에서 detach로 딱 분리시켜서 그냥 따로 쓰는거, 그 다음에 remove()는 실제 데이터베이스의 delete 쿼리를 날리고 싶을 때.

영속성 컨텍스트라는 개념이 있음으로 해서 얻을 수 있는 이점들이 있는데 1차 캐시, 동일성 보장 등등이 있습니다.

1차 캐시는 한번 조회했던 것을 또 조회하면 DB에 쿼리가 안 날라간다는 거죠. 물론 동일한 트랜잭션 안에서. 사실 고객이 막 동시에 10명이 접근했어요. 그러면 고객마다 별도의 1차 캐시를 가진다고 보시면 돼요. 사실상 성능 상 얻을 수 있는 이점이 그렇게 크진 않아요.

성능보다는 이 메커니즘을 통해서 얻을 수 있는 이점들이 있는 거예요. 그래서 동일성 보장은 == 해도 같다고 나온다. 왜냐? 1차 캐시해서 똑같이 가져온 것이니까.

그 다음에 트랜잭션을 지원하는 쓰기 지연. 버퍼링이죠. write를 쫙 모았다가 한 번에 딱 write 할 수 있는.

그 다음에 변경 감지, update를 할 때 변경된 걸 JPA가 자동으로 인식해서 알려주는 거.

그 다음에 지연 로딩 이라는게 있는데 이거는 나중에 설명해 드릴게요. 지연 로딩은 member.getTeam() 할 때, team의 쿼리를 나중에 날리는 거예요. 지연 로딩은 실무에서 되게 중요한 기능이어서 지겹도록 볼 겁니다.

그 다음에 플러시 설명 드렸고요.

그냥 플러시는 AUTO 모드로 써라. 웬만하면 손 대지 말고 트랜잭션을 커밋하거나, 쿼리를 실행할 때 플러시가 된다는 정도면 이해하시면 됩니다. 그리고 내가 직접 플러시 할 수 있죠.

자 그래서 플러시는 영속성 컨텍스트를 비우는 것이 아니라, 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화하는 거다 라고 설명 드렸고요.

이게 진짜 사실 중요한 건데 JPA를 쓰면 데이터 동기화나 이런 것들이 걱정이 될 수 있어요. '1차 캐시에 데이터가 있고, DB에 반영이 안 되면 어떻게 되지?' 고민들이 많으실 수 있는데 사실 크게 걱정을 안 해도 되는 이유가 뭐냐면 결국 트랜잭션이라는 작업 단위별로 메커니즘이 다 돌아가요.

그러니까 영속성 컨텍스트도 웬만하면 영속성 컨텍스트랑 트랜잭션의 주기를 맞춰서 설계가 들어가야 돼요. 그래야 문제가 없어요.

그래서 트랜잭션을 시작하고 끝나버리면, 영속성 컨텍스트도 거기서 시작해서 거기서 딱 끝나버려요. 그렇게 설계가 돼야 돼요. 그렇게 개발을 해야 이런 데이터 동기화 같은 게 아무 문제가 없어요.

아무튼 결론적으로 JPA를 쓸 때도 이 트랜잭션 작업 단위에 많은 걸 위임하고 쓰기 때문에, 그리고 트랜잭션 커밋 직전에만 동기화하면 되기 때문에 크게 데이터 동기화에 대한 이슈는 없다고 보면 됩니다.

그 다음에 준영속 상태 설명 드렸구요.

오늘은 여기까지 하겠습니다.