벌써 우테캠의 2주 차 순서인 JPA도 얼마 남지 않았다. 시간이 정말 빠른거 같다! 특히 최근 2~3주 동안 너무너무 바빴어서 더 그런 거 같다. 암튼 오늘의 포스팅 주제는 @EnableJpaAuditing 어노테이션이다. JPA 첫번째 과제를 하다가 배우고 느낀 것들을 정리해보고자 한다! 사건의 발단 created_at timestamp not null, updated_at timestamp, 여러개의 엔티티를 DDL을 참고하여 JPA 매핑 작업을 하고 있었고, 대부분의 엔티티에는 위의 컬럼들이 공통적으로 구현되어 있었다. 나는 첫번째 회사에서도 사용해본 경험이 있었어서 바로 저 부분을 공통 클래스로 구현하여 상속을 받는 구조로 구현을 시도했다! 더불어 EnableJpaAuditing 기능을 사용하여..

동시성 이슈 문제를 해결했던 업무 회고를 작성했던 지난 포스팅에 이어서 동시성 이슈 문제의 해결 방법 중 하나인 Lock이라는 거에 대해서 좀 더 자세히 알아보고자 한다. 지난 포스팅에서 나는 동시성 이슈를 JPA의 Lock Annotation을 이용하여 대응을 하였다. 동시성 이슈에 대해서 공부 하다보면 대응을 위해서 Redis 데이터베이스를 썼다는 이야기가 많이 나온다. 대략적인 이유를 보면 '단일 스레드 처리 방식과 데이터 잠금의 차이'라고 나와있다. 나는 그래서 Lock을 사용하고자 했던 거고 이번 기회에 Lock에 대해 더 공부를 하게 되었다. Lock? Lock이란 트랜잭션 처리의 순차성을 보장하기 위한 방법으로, 같은 데이터에 동시에 접근하는 경우 데이터의 일관성과 무결성의 유지를 위해 사용..

회사에 SaaS Portal을 개발을 진행한 지 반년이 막 넘어갈 때쯤 일 것이다. 기획과 개발 초기에는 프로젝트 규모가 굉장히 작았기 때문에 순수 Spring Data JPA만을 활용하여 데이터 CRUD 메서드 쿼리를 활용했는데, 규모가 커지면서 테이블 스키마도 복잡해지고, 조회 쿼리가 점점 복잡해지면서 JPA @Query Annotation을 이용하여 JPQL을 사용하는 일이 많아지고 직접 쿼리를 작성하는 일이 많아졌는데, 그러다 보니 스키마가 약간 변경이 될 때마다 수정해야 하는 쿼리들과 로직들이 많아지고 쿼리를 '직접' 쓰다 보니 수정점을 찾기가 힘들어지고 결국엔 수정점을 놓쳐 에러를 많이 내곤 했었다. 그래서 나는 '객체지향 쿼리 언어'인 Querydsl을 도입하게 되었다. 도입에 타당한 근거가..