[JDBC 라이브러리 구현하기 - 4단계] 페드로(류형욱) 미션 제출합니다. #918
Conversation
…가 없는 경우 리소스를 해제하도록 변경
| public Object invoke(MethodInvocation invocation) throws Throwable { | ||
| TransactionStatus transactionStatus = platformTransactionManager.getTransaction(new DefaultTransactionDefinition()); | ||
| try { | ||
| Object result = invocation.getMethod().invoke(invocation.getThis(), invocation.getArguments()); |
There was a problem hiding this comment.
invocation.proceed()를 활용해보는 건 어떨까요?
There was a problem hiding this comment.
정보를 이것저것 끄집어 내서 쓰는 것 같아서 뭔가 맘에 안 들었는데 훨씬 깔끔해졌네요! 감사합니다😊
| @BeforeEach | ||
| void setUp() { | ||
| final var user = new User("gugu", "password", "hkkang@woowahan.com"); | ||
| userDao.insert(user); | ||
| proxyFactoryBean.setProxyTargetClass(true); |
There was a problem hiding this comment.
스프링은 JDK dynamic proxy를 default로 둔 반면에 스프링 부트는 CGLib Proxy를 default로 둔 이유는 무엇일까요?
There was a problem hiding this comment.
서로 지향하는 관점이 조금 다르다고 생각합니다. 스프링은 스프링 부트에 비해 등장 시기가 (당연히) 이르기도 하고, 제 기준에서 스프링은 조금 날 것의 기술이예요. CGLib은 태생적으로 리플렉션 기반의 Dynamic Proxy보다 성능이 좋을 수 밖에 없는데, CGLib 등장 초기에는 성능 문제가 있어 오히려 다이나믹 프록시가 성능이 더 좋았다고 해요. 이러한 이유 때문에 Spring Framework에서는 JDK Dynamix Proxy가 기본값이었지 않나 싶어요. DI 컨테이너의 특성상 인터페이스를 권장하는 방향으로 기본값이 설정됐을 수도 있겠네요.
반면 SpringBoot의 경우에는 'Spring Framework의 쉬운 사용'을 컨셉으로 하고 있어요.
JDK 프록시는 다음과 같은 불편을 안고 있습니다.
- 인터페이스 생성을 강제
- 빈 주입 시 인터페이스로만 주입받을 수 있음 (구체 클래스 주입 불가)
시간이 지나면서 CGLib방식이 성능과 안정성 면에서 많은 개선이 있었고, 이러한 불편을 해소할 수 있다면 정책을 변경해도 된다고 판단했을 것 같아요. Spring 3.2부터 CGLib이 내장되면서 더 이상 외부 라이브러리를 사용하지 않아도 된다는 점도 선택에 영향을 미쳤을 것 같네요.
- https://stackoverflow.com/a/56248189/23619981 좀 지난 글이긴 한데, Phil의 답변도 찾을 수 있었습니다!
우주는 이유가 뭐라고 생각하시나요?
There was a problem hiding this comment.
저도 첫번째 이유는 쉽게 사용하기 위함이라고 생각합니다!
그동안 CGLIb를 내장하지 못했던 이유는 스프링 공식 문서에 나와있는 생성자를 2번 호출하는 문제 때문이라고 생각해요.
Objenesis 라이브러리의 등장으로 위 문제를 해결하고 그 때부터 CGLib를 default로 설정한 것이라 추측합니다!
As of Spring 4.0, the constructor of your proxied object is NOT called twice anymore, since the CGLIB proxy instance is created through Objenesis. Only if your JVM does not allow for constructor bypassing, you might see double invocations and corresponding debug log entries from Spring’s AOP support.
안녕하세요 우주! 드디어 마지막 미션의 마지막 단계까지 오게 됐네요🔥
끝까지 같이 파이팅해봐요😁