service 계층에서 @Transactional(readOnly = true) 임에도 불구하고 insert 쿼리가 나가는 것을 보게 되었다. @Transactional(readOnly = true)의 정의대로라면 DB에 변경을 가하는 CUD 작업 즉 insert, update, delete는 불가능하다. 이번 글에서는 왜 readOnly 트랜잭션에서 insert 쿼리가 나갈 수 밖에 없었는지 알아보고자 한다. @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) @Entity public class Team { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "team_id..
김영한님의 스프링 강의를 들어오면서 CUD에는 @Transactional을 R에는 아무 어노테이션을 붙여오지 않았다. 이게 정석인 줄 알았는데 같이 프로젝트를 진행한 팀원이 service 계층의 모든 메소드에 해당 어노테이션을 붙이는 것을 보고 관련 내용들을 찾아보니 이 3개가 엄연히 말하면 모두 다른 것이었다. 이번 글에서는 @Transactional, @Transactional(readOnly = true), 트랜잭션 어노테이션 없음 간 동작방식의 차이에 대해서 자세히 알아보고자 한다. public class Service { @Transactional public void createOrUpdateOrDeleteSomething() {} @Transactional(readOnly = true) pu..
프로젝트를 진행하다 OSIV라는 단어를 듣게 되었다. 그럼 트랜잭션과 DB connection 간의 상관관계는 어떻게 되지?라는 의문이 들어 이참에 각 개념들을 정리하고자 한다. 먼저 트랜잭션의 정의를 먼저 보고 가자. 하나의 작업을 수행하기 위해 필요한 데이터베이스 연산들을 모아 놓은 것으로, 데이터베이스에서 논리적인 작업의 단위가 된다. 만약 A가 B에게 자신의 통장에서 1만원의 금액을 송금한다면 SQL 상 A의 계좌에서 1만원이 마이너스되고, B의 계좌에는 1만원이 플러스되는 작업이 모두 수행되어야 한다. 만약 A의 계좌에서만 1만원이 빠져나가고 B의 계좌에는 1만원이 들어오지 않는다면 이는 데이터베이스의 무결성과 일관성이 깨지게 되는 결과를 낳는다. 따라서 각 2개의 SQL을 하나의 작업 단위로 ..
- Total
- Today
- Yesterday
- spring boot
- QueryDSL
- FrontController
- Spring Security
- servlet filter
- 디자인 패턴
- rest api
- Front Controller
- spring
- 전략 패턴
- facade 패턴
- ParameterizedTest
- vscode
- Git
- Linux
- spring aop
- 템플릿 콜백 패턴
- SSE
- Transaction
- 모두의 리눅스
- Java
- 서블릿 컨테이너
- mockito
- 단위 테스트
- Assertions
- github
- JPA
- C++
- junit5
- Gitflow
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |