몇 주 전 Real MySQL을 공부하며 정리했던 내용을 팀원들에게 공유한 적 있다. 오늘 들은 스프링 수업에서 이를 다루어서, 노션 페이지에 있는 포스팅을 블로그에 옮긴다. 트랜잭션 트랜잭션은 작업의 완전성을 보장해 준다. 논리적인 작업 셋을 모두 완벽하게 처리하거나, 처리하지 못 할 경우에는 원 상태로 복구해 작업의 일부만 적용되는 현상(Partial Update)이 발생하지 않게 만들어준다. 잠금과 트랜잭션은 비슷한 개념 같지만, 잠금은 동시성을 제어하는 기능이며 트랜잭션은 데이터 정합성을 보장 트랜잭션은 DBMS의 커넥션과 마찬가지로 최소의 코드에만 적용하는 것이 좋다. 트랜잭션의 범위를 최소화하라! 특히, 네트워크 작업 등 긴 시간이 걸리는 작업은 제외해야 한다. 메일 전송, 파일 전송 등 외부..

서비스 계층에서 아래의 modify 메소드를 작성하였고, 두 번째 이미지의 테스트 코드를 작성했다. modify 메소드는, PK로 Board를 가져온 뒤 내용과 제목을 변경한 후 save하는 메소드다. 서비스 계층에는 트랜잭션이 없으므로, 변경감지를 사용하지 않고 save 메소드를 통해 엔티티를 변경하였다. BoardService를 주입받은 뒤 아래의 modifyTest() 메소드를 실행한 결과 could not initialize proxy [com.example.board.entity.Board#2] - no Session org.hibernate.LazyInitializationException: could not initialize proxy [com.example.board.entity.Boar..

에러 메시지 Caused by: javax.persistence.TransactionRequiredException: No EntityManager with actual transaction available for current thread - cannot reliably process 'persist' call 웹 개발중 테스트 데이터를 매 실행마다 입력하기 번거로워서 jpa: hibernate: ddl-auto: create update로 변경할까 하다가, 그냥 애플리케이션이 실행할때마다 샘플 데이터를 저장하기로 했다. 일단 트랜잭션이 걸려있는 Service 단에서 sampleData 메소드를 작성했다. 빈 생성(여기서는 해당 코드가 있는 Service 클래스)과 의존관계 주입이 완료된 다음, sa..

트랜잭션 문제 해결 - 트랜잭션 템플릿 앞서 트랜잭션 매니저를 통해 트랜잭션 추상화, 리소스 동기화를 얻는데에는 성공했다. 그 덕에 서비스 코드는 이제 JDBC 기술에 의존하지 않으며 트랜잭션 동기화 매니저 덕분에 커넥션을 파라미터로 넘기지 않아도 된다. 하지만 트랜잭션을 사용하는 로직을 살펴보면 다음과 같은 패턴이 반복되는 것을 확인할 수 있다. 트랜잭션 사용 코드 //트랜잭션 시작 TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition()); try { //비즈니스 로직 bizLogic(fromId, toId, money); transactionManager.commit(status); /..

애플리케이션 구조 여러가지 애플리케이션 구조가 있지만, 가장 단순하면서 많이 사용하는 방법은 역할에 따라 3가지 계층으로 나누는 것이다. 이 3개의 계층 중 핵심 비즈니스 로직이 들어있는 서비스 계층이 가장 중요하다고 가히 말 할 수 있다. 시간이 흘러서 UI(웹)와 관련된 부분이 변하고, 데이터 저장 기술을 다른 기술로 변경될 순 있어도, 비즈니스 로직은 최대한 변경없이 유지되어야 한다. 이렇게 하려면 서비스 계층을 특정 기술에 종속적이지 않게 개발해야 한다. --> 사실 계층을 나눈 이유도 서비스 계층을 순수하게 유지하기 위한 목적이 크다. 기술에 종속적인 부분은 프레젠테이션 계층, 데이터 접근 계층에서 가지고 간다. --> 예를 들어서 HTTP API 를 사용하다가 GRPC 같은 기술로 변경해도 프..

DB 락 - 개념 이해 세션1이 트랜잭션을 시작하고 데이터를 수정하는 동안 아직 커밋을 수행하지 않았는데, 세션2에서 동시에 같은 데이터를 수정하게 되면 여러가지 문제가 발생한다. 바로 트랜잭션의 원자성이 깨지는 것이다. 여기에 더해서 세션1이 중간에 롤백을 하게 되면 세션2는 잘못된 데이터를 수정하는 문제가 발생한다. 이런 문제를 방지하려면, 세션이 트랜잭션을 시작하고 데이터를 수정하는 동안에는 커밋이나 롤백 전까지 다른 세션에서 해당 데이터를 수정할 수 없게 막아야 한다. 데이터베이스는 이런 문제를 해결하기 위해 락(Lock)이라는 개념을 제공한다. 세션1은 트랜잭션을 시작한다. 세션1은 memberA 의 money 를 500으로 변경을 시도한다. 이때 해당 로우의 락을 먼저 획득해야 한다. 락이 남..