1. failed to lazily initialize a collection of role: could not initialize proxy - no Session 사태의 발생
트랜잭션,영속성 컨텍스트,Proxy 들을 알아보자~
시큐리티를 통해서 들어오는 User객체를 준영속상태로 들어와서 DB에 다른 객체에 넣어주거나 변수에 넣어주는등 영속성 컨텍스트로 재생성해주지 않고는 DB에 데이터를 넣어줄수 없기때문에 일어나는 오류였다. 금요일날알고 일요일날 다시 한번 고민하면서 깨달은 기념적인 순간..
2. 영속성 컨텍스트
JPA는 객체지향 언어인 JAVA와 Database 사이의 패러다임 불일치를 해결하기위해서 사용되는데 이 JPA가 사용하는것이 영속성 컨텍스트(Persistence Context)인데 뜻 자체는 영구 저장하는 환경이다
3.@Transcational 어노테이션
@Transactional어노테이션은 일반적으로 DB에서 데이터를 조회, 생성, 삭제, 수정 을 하는경우 메소드 상단에 @Transactional어노테이션을 붙이고 설정값은 readOnly정도만 사용하지만 대용량 동기화, 배치등을할때 트랜잭션 설정값을 사용해야 한다고 한다.
4. 트랜잭션의 4가지 특징(ACID)
1.원자성(Atomicity)
2.일관성(Consistency)
3.격리성(Isolation)
4.영속성(Durability)
5. 트랜잭션 격리성으로 인하여 벌어지는 문제점을 해결하기 위한 트랜잭션 격리수준 4단계
- 1단계 (1) Read Uncommitted
한 트랜잭션에서 커밋하지 않은 데이타에 다른 트랜잭션이 접근 가능하다. 즉, 커밋하지 않은 데이타를 읽을 수 있다.
발생 문제점 : Dirty Read, Non-Repeatable Read, Phantom Read - 2단계 (2) Read Committed
커밋이 완료된 데이타만 읽을 수 있다.
발생 문제점 : Non-Repeatable Read, Phantom Read - 3단계 (3) Repeatable Read
트랜잭션 내에서 한번 조회한 데이타를 반복해서 조회해도 같은 데이타가 조회 된다
발생 문제점 : Phantom Read - 4단계 (4) Serializable
트랜잭션 내에서 쿼리를 두 번 이상 수행할 때, 첫 번째 쿼리에 있던 레코드가 사라지거나 값이 바뀌지 않음은 물론 새로운 레코드가 나타나지도 않도록 하는 설정입니다.
위 3가지 문제점을 모두 커버 가능하다. 하지만 동시 처리 성능은 급격히 떨어질 수 있다.
6.UsernamePasswordAuthenticationToken(시큐리티)
인터페이스 Principal에서 상속받은 인터페이스 Athentication
추상클래스로서 Athentication 를 넣은 AbstratAuthenticationToken
그리고 이 내용을 구현한 구현클래스가UsernamePasswordAuthenticationToken입니다.
다형성의 개념을 가지고 있다.
Principal -> Athentication -> AbstratAuthenticationToken -> UsernamePasswordAuthenticationToken
다형성으로 한 메소드 안에서 구현하면서 userId를 넣어줄경우
Authentication newAuth = new UsernamePasswordAuthenticationToken(
userId, null, userDetails.getAuthorities());
7.Authentication
UsernamePasswordAuthenticationToken 구현체 및 세션 정보를
보관하는 객체에서 필요한 정보를 뽑아내는 메소드를 가지고 있습니다
Authentication이 반환하는 방법 4가지
Object getPrincipal() : 첫 번째 생성자로 주입한 객체 반환
Object getCredentials() : 두 번째 생성자로 주입한 객체 반환
Collection<? extends GrantedAuthority> getAuthorities() : 세 번째 생성자인 권한 리스트 객체 반환
Object getDetails() : 세션정보를 가진 WebAuthenticationDetails 객체 반환
8. 예외처리 방법 3가지
- 메소드내에서의 try-catch(-finally)를 이용한 예외처리
- 컨트롤러 단에서 행하는 예외처리( @ExceptionHandler라는 어노테이션을 붙인 메소드를 하나 생성하여 발생할 예외처리 내용을 안에 넣어주고 예외를 처리한다.)
@ExceptionHandler({IllegalArgumentException.class, TokenMgrError.class})})
public String ExceptionHandler(Exception e) {
user.error(e.getMessage());
return "400";
}- 전역처리(여러 클래스의 예외를 하나의 클래스를 생성하여 이 클래스로 모두처리하는 방법)
처리방법은 컨트롤러와 어노테이션에 따라서 종류가 다르게된다.
(@ControllerAdvice, @RestControllerAdvice(@ControllerAdvice + @ResponseBody))
@RestControllerAdvice
public class ApiExceptionHandler
//Dto형태로 보내고 싶다면 이런형태로
@ExceptionHandler(IllegalArgumentException.class)
public ResponseEntity<Object> apiHandlerRequestException(IllegalArgumentException ex) {
log.warn(ex.getMessage());
return new ResponseEntity(
restApiException,
HttpStatus.BAD_REQUEST
);
}
//문자열로 보내고 싶다면 이러한 형태로 하면된다.
@ExceptionHandler(TestException.class)
public String testHandlerException(Exception e) {
log.warn(ex.getMessage());
return "/400";
}컨트롤러의 어노테이션이 @Controller라면 ControllerAdvice을 붙여줘야한다.
-
AOP를 이용한 전역예외처리나 컨트롤러 단에서의 AOP예외처리도 있다.
-
@Slf4j
로깅에 대한 추상 레이어를 제공하는 인터페이스의 모음이다. (로깅 Facade)
인터페이스를 사용하여 로깅을 구현하게 되면 좋은 점은 추후에 필요로 의해 로깅 라이브러리를 변경할 때 코드의 변경 없이 가능하다는 점이다.
예시
@Slf4j
public class TestController {
@GetMapping("/")
public String String(String str){
try {
str.toString();
} catch (NullPointerException e){
log.trace("가장 디테일한 로그");
log.warn("경고");
log.info("정보성 로그");
log.debug("디버깅용 로그");
log.error("에러",e);
}
return "test";
}
}로깅 레벨은 (많은 로깅) trace > warn > info > debug > error (적은 로깅) 순이다.
