기본적으로 스프링에서 사용되는 선언적 트랜잭션에는 옵션과 Default값이 적용되어 있는데.. 가장 많이 사용되는 것은 readOnly(기본값 false)옵션일 듯 하다. 그리고 CheckException의 경우에는 발생하더라도 롤백처리가 되지 않는데.. 롤백하기를 원한다면 옵션으로 설정이 가능하다..!(기본적으로 RuntimeException이 발생하였을때만 자동 롤백처리됨.) @Transactional(readOnly = true) @Transactional(rollbackFor = Exception.class) isolation와 timeout또한 옵션으로 설정 가능하지만..DB에 따라 지원 가능 할 수도 있고 아닐수도 있다고 한다..! 필요하다면 사용하고 적용이 되는지 제대로 확인이 필요하다..!..

개인적인 정리입니다....! 모든 내용은 인프런에 있는 김영한님 강의 중 스프링 DB 2편에 나오는 내용입니다. 스프링에서 제공하는 트랜잭션을 사용 하기위헤서는 해당 트랜잭션을 적용하는 방식에 대해서 알아야 하는데… @Transactional 스프링의 경우에는 위의 Transactional 어노테이션을 명시하여 사용하고 이 경우를 선언적 트랜잭션 관리라고 한다. 다양한 방식이 존재하지만 현재는 해당방식을 가장 많이 사용한다.(Proxy 방식의 AOP가 적용된다.) 이전 회사에서는 서비스단의 메서드 이름에 대해 컨벤션을 지정해놓고 프로그래밍단에서 트랜잭션이 어떤 것이 사용 될지에 대해 스프링 실행시에 지정되도록 되어 있었다. (예를들어 select로 시작하는 경우 readOnly 적용 update 시작 되..

일단 TDD란 구글 검색시에 다음과 같이 정의되어 있다. 테스트 주도 개발(test-driven development, TDD)은 소프트웨어 개발 방법론 중의 하나로, 선 개발 후 테스트 방식이 아닌 선 테스트 후 개발 방식의 프로그래밍 방법을 말한다. 개발을 진행하면서 테스트 하기도 어렵고, 특정 부분만 떼어다가 좀 테스트를 하고싶은데 어떻게 해야 편하게 가능한거지..?? 그런 생각을 많이 하다보니 TDD란 방식에 빠져있었는데 인터넷에 떠도는 예제 코드나 강의를 듣는 도중 알려주는 몇가지 방식에 대한 테스트 들만 보다보니 뭔가 너무 기본기 없이 시작했다는 느낌을 강하게 받아왔다. 그 기본기가 되어 줄 수 있는 책이길 기대하며 유명한 책을 구매했다..! 교보문고에서 구매했고.. 아래 주소이다.(책 판매 ..

기본적인 권한의 경우 크게 3개로 분류하려고 한다. 상세로 CRUD등등 너무 나누게 될 경우.. 기본틀만 잡다가 스트레스로 쓰려질..것 같았다.. 기본적인 관리자(ADMIN)이 존재하고 관리자는 일단 총 3종류로 분류된다. (시스템관리자, 일반관리자, 서브관리자) 관리자들은 각각의 어드민 그룹을 가지게 되며 그룹에 부여된 메뉴리스트를 보게된다. ADMIN ADMIN_GROUP 1대1 ADMIN_GROUP MENU 1대1 그리고 요청별 상세에 대한 권한의 경우 메서드별로 어노테이션을 적용하여 Interceptor나 필터에서 체크하려고 한다. 기본적인 생각은 아래처럼 하려고 한다. 시스템관리자의 경우 모든게 가능. 일반관리자의 경우 CRUD를 비롯한 대부분이 가능 하지만 특정 민감한 부분이 생기면 그 부분을..

개인적으로 토이프로젝트나 회사 일 로써 하는게 아닌 개인으로 하는 프로젝트가 거의 없었다. 첫 회사에서 했던게 CMS였기도 하니까. 그 기억을 되살려서 JPA를 기반으로 한 프로젝트를 하나 만들어 봐야겠다. ADMIN을 먼저 만들고 그 이후에 테이블 관계도랑 여러가지 생각들을 여기 정리하는 형태로 진행 하려고 생각중이다..! 그보다 CMS란....? CMS(Content Management System: 콘텐츠 관리 시스템) 으로써 그냥 내가 생각하기에는 여러가지 시리즈가 많은데.. 그중 유명한 것은 cafe24에서 제공하는 여러가지 템플릿 형태의 사이트 관리 프로그램이다. 어드민 내에 다양한 기능을 포함하고 있고 해당 기능들을 사용하여 개발을 모르는 운영자들이 편리하게 해당 기능을 사용 할 수 있게 도..

김영한님의 강의를 보면서 무의식적으로만 알고 넘어가던 부분들에 대해 정리를 하려고 한다. 기본적인 예외의 구조는 다음과 같다. 보통의 경우 가장 많이 맞이하는 NullPointExcepiton의 경우 언체크 예외로 취급되며 컴파일시에 체크가 되지않아.. 어디서 언제 발생했는지 항상 문제가되며 잘 검증하고 체크하지 않는경우 언제 어디서든 찾아와서 반겨준다. 기본적인 큰 틀의 경우 체크, 언체크 예외의 기준은 컴파일러가 해당 코드를 컴파일시 예외처리에 대해서 신경을 써서 알려주는지 아닌지 여부에 따른다. 체크 예외처리가 필요한 곳이 있는데 throw하지 않거나 try,catch 처리 하지 않는다면 컴파일시 해당 부분이 문제가 된다고 알려주기 때문에 컴파일러가 체크 해준다고 하여 체크예외! 라고 기억하면 좋을..