🤔 문제 상황DB 조회 시 성능 최적화는 개발자들이 자주 마주치는 과제이다.특히 복잡한 엔티티 관계와 다양한 응답 값 설정이 필요한 상황에서는 더욱 그렇다. 이러한 맥락에서 findByXXX() 메소드를 사용하여 DB에서 직접 필터링하는 방식과 findAll()로 모든 데이터를 가져온 후 Java의 stream API를 이용해 필터링하는 방식 중 전자가 더욱 성능에 좋다고는 알고 있었지만, 어떻게/ 왜 더 효율적인지에 대한 의문이 생겼다.실무에서는 종종 findAll()을 사용한 후 stream의 filter 등으로 데이터를 가공하는 접근법을 볼 수 있었다. 이는 주로 빠른 개발 속도를 위해 선택되며, 복잡한 연관 관계에서 SQL 쿼리 작성에 시간을 들이는 대신 컴파일 시점에 확인 가능한 stream ..
🤔 문제 상황스케줄러를 사용하고 있는 프로젝트가 있다. 해당 스케줄러가 주기적으로 동작하던 와중 아래와 같은 롤백 예외 로그가 찍혔다.... ERROR ... [askScheduler-10] c.w.b.b.l.CreateDeliveryMessageListener : org.springframework.transaction.TransactionSystemException: Could not commit JPA transaction; nested exception is javax.persistence.RollbackException: Transaction marked as rollbackOnlyat o.s.orm.jpa.JpaTransactionManager.doCommit(JpaTr..
데브코스에서 팀플을 진행중에 로그인한 사용자들을 확인후 id를 가져오는 AOP를 만들었다. 그 중 일부 내용을 발췌한 것 인데, 대략적으로 아래 코드와 함께 요약하면 로그인을 한 상태에서 로그인한 사용자의 ID가 필요한 메서드에 @CurrentMemberId를 붙이면 해당 메서드의 파라미터들의 값들을 불러와 memberId가 있으면 로그인한 사용자의 memberId로 매핑해 주는 것이다. 다시 AOP 코드로 가서, 여기서 봐야할 것은 parameterName 인데 이 AOP를 적용한 팀원분의 로컬에서는 해당 메서드들의 파라미터들의 갯수만큼 for문을 돌며 각 파라미터의 값들이 잘 불러와졌다. (ex memberId 등) 하지만 내 로컬에서는 되지 않아, 콘솔로 찍어보니 맨 아래의 parameterName..
