CheerUp_Cheers

목차   개요동시성을 제어하는 방법은 여러가지가 있고, 필자의 회사에서는 주로 @Transactional와 낙관적 락을 사용하여 처리를 하는 편이다. 하지만, 프로젝트를 꽤나 진행이 된 이후에 위의 구조를 사용하는 로직이 많은 오류를 뱉게 되었다.기존에 설계 목적과 다르게 하나의 컬럼에 대해서 지독하게 UPDATE를 진행하게 되었고, 낙관적 락의 특성상 기존의 상태가 변경되면 업데이트 처리를 하지 않고 오류를 발생시키기 때문이었다. '이런 상황에서는 어떻게 개선을 할 수 있을까?''개선을 할 수 있는 시간적, 기술적 여건이 충분할까?'를 시작으로 해당 이슈를 어떻게 처리했는지에 대해서 작성하고 싶어 글을 작성하였다. '어? 이거 이렇게 사용해도 괜찮나요?' 라고 의견이 나올 수 있고, 더 나은 방법도 있..

AOP의 특징? 1. 공통적인 처리. 2. 코드의 중복을 막고, 따로 관리가 가능 3. 관리가 용이(흐름의 앞, 중간, 뒤 처리가 가능). # 들어가기전 [1] DispacherSevlet? Servlet 해당 어플리케이션에 들어오는 모든 요청을 핸들링 -> 기존에는 web.xml에 등록 모든 요청을 Contorller로 보내 버리기 때문에, Css, Javasciprt등의 파일마저 가로챔 -> 클라이언트의 요청을 2가지로 분리하여 구분하여 해결 1) /apps의 URL로 접근시 디스패처 서블릿이 담당 2) /resources의 URL로 접근시 담당 X [2] HttpServletRequest(extended ServletRequest) 클라이언트의 요청과 관련된 정보와 동작을 가지는 객체 -> 클라이언..