로키의 개발 블로그

리액트란? 리액트는 페이스북에서 개발한 사용자 인터페이스를 만들기 위한 자바스크립트 라이브러리입니다. 리액트는 프레임워크가 아닌, 라이브러리입니다. 따라서 MVC(Model-View-Controller)와 MVW(Model-View-Whatever) 등의 아키텍쳐를 가진 프레임워크와는 달리 오직 뷰만을 관리합니다. 다른 웹 프레임워크가 AJAX, 데이터 모델링, 라우팅 등의 기능을 내장하는 반면 리액트는 기타 기능을 직접 구현하거나 다른 라이브러리를 추가해 사용해야 합니다. 렌더링이란? 렌더링이란 사용자 화면에 뷰를 보여주는 것을 말합니다. 리액트에서는 렌더링을 '초기렌더링'과 '리렌더링'으로 구분합니다. 초기렌더링 초기렌더링은 맨 처음 화면에 보이는 뷰를 정의하는 동작을 말합니다. 리액트에서는 rend..

현 프로젝트에서 분산락을 적용하는 방법은 MySQL의 USER_LEVEL_LOCK, 즉 NAMED_LOCK 방식입니다. NAMED_LOCK은 get_lock() 함수를 이용해 임의의 문자열에 대해 잠금을 거는 방식으로 동작합니다. 따라서 임의의 문자열인 LockName이 반드시 지정되어야 합니다. 분산락 AOP를 사용하는 요청이 발생할 때마다, 분산락 Advice에서 파라미터에 @LockName 애노테이션이 존재하는지 검사하며, 해당 파라미터가 존재하지 않으면 다음 그림과 같이 런타임예외를 던지는 구조로 동작합니다. 위처럼 LockName애노테이션의 부재로 인해 예외를 던지는 것은 사용자의 잘못된 요청이 아닌 개발자의 실수가 원인입니다. 또한, 예외 처리 과정에서 별도의 핸들링 로직 없이 사용자에게 5X..

분산락 중첩 적용 특정 사용자 요청을 처리하는 경우 분산락에 대한 중첩 적용이 필요했습니다. 모임을 생성하는 경우로 예시를 들어보겠습니다. 모임을 생성하는 요청은 우선, 회원에 대한 분산락을 획득하여 한 회원이 모임 생성 제한 갯수를 초과하여 생성하는 것을 검사합니다. 그 후, 모임이름에 대한 분산락을 획득하여 동일한 이름의 모임이 생성되는 것을 검사한 후 모임을 생성합니다. 따라서 다음과 같이 메서드를 분리하여 각 메서드에 별도의 분산락 적용을 위한 AOP를 적용했습니다. 컨트롤러 @Service @RequiredArgsConstructor public class ClubService { @DistributedLock(prefix = DistributedLockPrefix.MEMBER_ID) publi..

이전 이슈를 통해 동시 요청시 중복 데이터 삽입 문제를 해결할 수 있었습니다. 그러나 아직 몇 가지 개선해야 할 점이 남아있습니다. 하드코딩된 lockname 파라미터 메서드 분리와 추상화 하드코딩된 lockname 파라미터 개선 현재 작성된 분산락 어드바이저는 다음과 같은 방식으로 lockname을 가져옵니다. String lockName = joinPoint.getArgs()[0].toString(); 위 방식은 분산락 AOP를 사용하는 경우 항상 첫번째 파라미터를 lockname 파라미터로 고정시키는 방식입니다. 하드코딩은 의미를 파악하기 어려우며 유지보수가 어렵다는 단점이 있으므로 분명히 개선해야할 문제입니다. 따라서 기존에 선언한 @DistributedLock 적용한 DistributedLock..

문제인식 개발 중 클라이언트로부터 동일한 데이터에 대한 삽입 요청이 동시에 들어오는 경우, 중복 데이터 검사 로직을 거치더라도 데이터가 중복 삽입되는 문제를 발견했습니다. 회원이 모임을 가입할 때 발생하는 문제를 예시로 들어보겠습니다. 위와 같은 로직을 거쳐 회원이 모임에 가입하는 경우입니다. 위처럼 클라이언트의 오류로 동일한 두 요청이 동시에 들어온 경우 회원이 한 모임에 중복으로 가입하게 되는 문제가 발생하게 됩니다. 이 문제는 간단하게 Unique 제약조건을 통해 해결할 수 있습니다. 그러나 만약 '모임에 역할을 부여하여 관리자 회원은 관리자 역할과 일반 역할로 중복 가입할 수 있다.'라는 요구사항이 추가되면 다음과 같이 DB의 제약조건을 변경해 주어야 합니다. 또한, 제약조건을 변경하는 불편함을 ..

Spring Transaction의 Self Invocation 이슈 문제 인식 Spring Security를 이용한 OAuth 로그인 기능을 구현하기 위해 커스텀한 OAuth2UserService를 개발하던 중, 영속 상태에 있는 인스턴스의 필드 변경 사항이 DB에 저장되지 않는 문제를 발견하였습니다. 로그를 출력하며 확인해본 결과, 영속성 컨텍스트의 스냅샷을 이용한 변경 감지(dirty checking)뿐만 아니라 트랜잭션을 지원하는 쓰기 지연도 정상적으로 동작하지 않았습니다. 문제가 발생한 코드는 다음과 같습니다. @Service @RequiredArgsConstructor public class OAuth2UserServiceImpl implements OAuth2UserService { priv..

모던 Practical 자바 5장 스트림 API를 읽다 흥미로운 코드를 발견했다. (설명을 위해 약간 변형했습니다.) List intList = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9); int sum = 0; intList.stream().forEach(n -> sum+=n); System.out.println("sum : " + sum); 문제가 전혀 없어보이는 코드지만, 다음과 같은 메시지와 함께 컴파일 에러가 발생한다. java: local variables referenced from a lambda expression must be final or effectively final 해석하자면 '람다식에서 참조되는 변수는 final 이어야 한다.'이다. 진짜 흥미로..

자바를 공부해본 경험이 있는 사람이라면 객체지향 프로그래밍에서 인터페이스가 얼마나 큰 비중을 차지하는지 알고 계실 거라 생각합니다. 이번 포스팅에서는 객체지향의 핵심 개념인 인터페이스의 문제점과 이를 해결하기 위해 자바에서 제공하는 기능에 대해 이야기해보고자 합니다. 인터페이스의 문제점 인터페이스는 동일한 목적의 동작을 수행하도록 구격을 정의하는 명세서의 역할을 하며, 이를 구현한 클래스에서는 구격에 맞춰 세부적인 동작을 작성합니다. 좀더 구체적으로 표현하면, 자바는 다형성을 사용하여 코드의 유연성을 확보하기 위해 인터페이스에서는 추상 메서드를 선언하고 implements 하는 구현체에서는 override 하여 구격에 맞춰 코드를 작성합니다. 객체지향 개발을 가능하게 해주는 인터페이스는 장점도 많았지만 ..

이전 포스팅에서는 스프링의 빈 후처리기인 AnnotationAwareAspectJAutoProxyCreator에 대해 알아보았습니다. [Spring] 스프링의 빈후처리기(AnnotationAwareAspectJAutoProxyCreator) 이전 프록시에서는 직접 빈 후처리기를 구현하였고 빈으로 등록되는 객체들을 프록시로 대체하는 작업을 진행해보았습니다. [Spring] 빈 후처리기(BeanPostProcessor) 이전 글에서는 프록시 팩토리의 yejun-the-developer.tistory.com 스프링 컨테이너의 빈 저장소에 실제 타깃 객체 대신 프록시를 등록하려면 대상 타깃 클래스들과 어드바이저(advisor)를 빈으로 등록하면 됩니다. 그러면 AnnotationAwareAspectJAutoPr..

이전 프록시에서는 직접 빈 후처리기를 구현하였고 빈으로 등록되는 객체들을 프록시로 대체하는 작업을 진행해보았습니다. [Spring] 빈 후처리기(BeanPostProcessor) 이전 글에서는 프록시 팩토리의 장점과 한계점에 대해 알아보았습니다. [Spring] 프록시 팩토리(ProxyFactory) 한계점을 다시 정리해보자면 다음과 같습니다. 프록시를 적용할 스프링 빈의 갯수만큼 yejun-the-developer.tistory.com 이번 포스팅에서는 수동으로 진행한 과정을 모두 자동으로 바꿔주는 스프링과 스프링 부트의 편리한 기능에 대해 자세히 알아보겠습니다. 우선, 스프링이 제공하는 빈 후처리기를 사용하기 위해선 aop 라이브러리를 추가해야 합니다. Gradle을 사용하는 경우, build.gra..