| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
- JPQL
- 지연 로딩
- MSA
- docker
- 페이징
- JWT
- Spring
- 쿠버네티스
- securitycontextholderfilter
- mybatis
- JPA
- @Transactional
- Spring Data JPA
- redis
- DLQ
- DI
- Web
- docker compose
- AWS
- Dead Letter Queue
- 컨테이너
- @ComponentScan
- Routing Key
- JdbcTemplate
- 스프링 부트
- 서블릿 컨테이너
- CORS
- Spring Container
- dockerhub
- kafka
- Today
- Total
목록transactionManager (2)
look-forest
스프링 트랜잭션 기본스프링 트랜잭션 추상화JDBC 기술과 JPA 기술은 트랜잭션을 사용하는 코드 자체가 다르다. 따라서 JDBC 기술을 사용하다가 JPA 기술로 변경하게 되면 트랜잭션을 사용하는 코드도 모두 함께 변경해야 한다.스프링은 이런 문제를 해결하기 위해 PlatformTransactionManager 라는 인터페이스를 통해 트랜잭션을 추상화한다. 선언적 트랜잭션과 AOP@Transactional 을 통한 선언적 트랜잭션 관리 방식을 사용하게 되면 기본적으로 프록시 방식의 AOP가 적용된다.트랜잭션 프록시가 트랜잭션 처리 로직을 모두 가져간다. 그리고 트랜잭션을 시작한 후에 실제 서비스를 대신 호출한다.트랜잭션 프록시 덕분에 서비스 계층에는 순수한 비즈니즈 로직만 남길 수 있다.스프링은 트랜잭션 ..
애플리케이션 구조 - 순수한 서비스 계층 시간이 흘러서 UI(웹) 와 관련된 부분이 변하고, 데이터 저장 기술을 다른 기술로 변경해도, 핵심 비즈니스 로직이 들어있는 서비스 계층은 최대한 변경없이 유지되어야 한다. 서비스 계층은 가급적 비즈니스 로직만 구현하고 특정 구현 기술에 직접 의존해서는 안된다. 이렇게 하면 향후 구현 기술이 변경될 때 변경의 영향 범위를 최소화 할 수 있다. 순수 JDBC로 구현 시 문제점트랜잭션을 사용하기 위해서 javax.sql.DataSource, java.sql.Connection, java.sql.SQLException 같은 JDBC 기술에 의존해야 한다. 향후 JDBC에서 JPA 같은 다른 기술로 바꾸어 사용하게 되면 서비스 코드도 모두 함께 변경해야 한다.핵심 비즈니..