[JDBC 라이브러리 구현하기 - 4단계] 디투(박정훈) 미션 제출합니다. #593
Conversation
| } catch (SQLException e) { | ||
| System.out.println(e.getMessage()); | ||
| rollback(connection); | ||
| throw new DataAccessException("transaction 설정에 오류가 발생했습니다."); |
There was a problem hiding this comment.
SQL Chekced Exception을 Unchecked로 바꿔서 Throw해주는 군요.
이럴 경우에, DataAccessException 에 메시지를 constant 하게 주는 것보다 SQlException e도 같이 넘겨보는건 어때요?
필수 반영사항은 아닙니다.
There was a problem hiding this comment.
이야 놓쳤네요. 감사합니당. 프린트도 지우고 로그로 바꿨어요.
| try (final PreparedStatement ps = createPreparedStatement(connection, sql, args)) { | ||
| return ps.executeUpdate(); | ||
| } catch (SQLException e) { | ||
| log.error(e.getMessage()); | ||
| throw new DataAccessException(e); | ||
| } finally { |
There was a problem hiding this comment.
트랜잭션 활성화 여부에 따라서, connection을 close 해주는 군요 잘 짜주신 것 같아요,
| final Connection connection = DataSourceUtils.getConnection(dataSource); | ||
| try { | ||
| connection.setAutoCommit(false); | ||
| TransactionSynchronizationManager.setActualTransactionActiveTrue(); |
There was a problem hiding this comment.
connection.setAutoCommit(false)랑 setActualTransactionActiveTrue안에 넣어보는건 어떨까요?
하나로 묶을 수 있는 작업인 것 같아요.
There was a problem hiding this comment.
TransactionSynchronizationManager는 트랜잭션 스레드를 관리하는 객체라고 생각해요. autoCommit을 false로 바꾸는 건 TransactionTemplate의 execute 메소드가 하는 것이 더 어울린다고 생각해서요. connection 관련 작업들을 처리해주고 있어서 외부에서 처리하면 헷갈릴 것 같아요.
또, 정리해주어야하는 자원이기 때문에 최대한 한 파일에서 실행하는 것이 편할 것 같습니다.
There was a problem hiding this comment.
납득되네요. TransactionSyncronizationManager가 jdbcTemplate 같은 곳에서도 쓰이긴 하니, setAutoCommit 같은 tx의 시작을 의미하는 메서드라인은 txTemlate에 있는게 낫겠네요
| } | ||
|
|
||
| public void execute(final TransactionCallback transactionCallback) { | ||
| final Connection connection = DataSourceUtils.getConnection(dataSource); |
There was a problem hiding this comment.
만약 TransactionTemplate 안에서 TransactionTemplate이 사용되면 어떻게 될까요?
문제가 생길수도 있을 것 같아요. 한 번 확인해보시면 좋을 것 같습니다.
|
|
||
| @BeforeEach | ||
| void setUp() { | ||
| dataSource = Mockito.mock(DataSource.class); |
There was a problem hiding this comment.
제가 요청 드린 테스트를 짜주셨군요.
아 DataSourceConfig가 없어서, Mockito.mock을 써주신거군요.
지금 TxSyncManager의 경우에는 단순하게 dataSource와 connection을 저장, 조회만 해서 mock으로만 해도 충분한 것 같아요.
There was a problem hiding this comment.
App에 있는 DataSourceConfig를 jdbc test 패키지에 넣어서 사용하는 방법도 있을 것 같고,
study 학습테스트에 있던 것 처럼 간단하게 datasource를 만들어 사용하는 방법도 있을 것 같네요.
| private final UserService userService; | ||
| private final TransactionTemplate transactionTemplate; | ||
|
|
||
| public TxUserService(final UserService userService, final TransactionTemplate transactionTemplate) { |
There was a problem hiding this comment.
TxUserService에서 UserService 인터페이스로 받는 군요.
저는 실수 할 수도 있어서 AppUserService가 적당하다고 생각해요. UserService라는 인터페이스의 경우는 추가적인 다른 UserService가 생길일도 없을 것 같거든요.
디투의 생각은 어떤가요?
| JdbcTemplate jdbcTemplate; | ||
|
|
||
| @BeforeEach | ||
| void setUp() { |
There was a problem hiding this comment.
jdbcTemplate의 경우에는 진짜 DataSource가 필요해요.
단순히 mock으로는 해결이 안 되죠.
이런 경우에 테스트만을 위한 클래스를 테스트 패키지에서 정의해서 사용하는 방식이 있을 것 같습니다.
(이제 테스트를 짜주실 필욘 없습니다. 짜기 위해 어떤 고민을 헀는가가 궁금했어요.
There was a problem hiding this comment.
의존성에 h2를 추가하는 것이 걸렸습니다. 모킹으로 생각해보았는데 DataSource와 Connection 메소드들을 다 만들어준다는 것이 리소스가 너무 많이 드는 작업이라고 생각했어요.
홍박사님 안녕하세요.
생각보다 오래 걸렸네요. 이전 코드에서 추가된 것 위주로 말씀드릴게요.
TransactionSynchronizedManager
이 객체는 트랜잭션들을 바인딩, 언바인딩, 혹은 트랜잭션의 리소스를 들고오는 역할을 합니다. 원래 이렇게 3가지 기능만 하다가 트랜잭션 시작 유무를 확인하기 위해서 actualTransactionActive를 만들었습니다.
TransactionTemplate
트랜잭션을 시작과 끝을 관리해주는 객체입니다.
TransactionCallback
트랜잭션으로 어떤 작업을 하는지 함수형 인터페이스로 전달해줍니다.