250210 월 TIL

@Transaction은 왜 service에 거는게 맞는가?

-일반적으로는 맞다.

-장점

1. 비즈니스 로직의 독립성 확보
-> 만약 controller에 건다면 controller가 아닌 다른 곳(다른 컨트롤러, 스프링 배치)에서는 올바른 트랜잭션이 일어나지 않게 된다.

2. 성능 향상

-> DB를 조회할 수 있는 객체가 있는데, 이 객체가 조회할 때 갯수 제한이 있다. 만약 controller에 트랜잭션을 건다면, 컨트롤러에서 서비스를 조회하고 서비스가 처리하고 결과를 다시 컨트롤러로 보내는 것보다, 서비스에서 처리 후 결과만 보내는게 DB를 점유하는 시간이 더 짧아진다. 점유 시간이 짧아지면 DB를 조회하는 객체를 더 적게 쓰니 다른 작업들이 기다리는 시간이 줄어들어 결과적으로 성능이 향상된다.

-단점

개별 트랜잭션이 여러개 실행된다.

1. 트랜잭션 처리 sql을 잘게 쪼갠다면 작은 DB 조회가 지속적으로 발생한다.

->이게 많아지면 그것도 부하가 된다.

2. 작은 서비스에서 서비스의 재사용이 무의미할 경우 컨트롤러에 트랜잭션을 걸 때 유의미한 성능 향상을 꾀할 수 있음.

 

결론: 서비스에 걸지 컨트롤러에 걸지는 각각 장점이 없는 것도 아니기에 상황에 따라 어디에 걸지 잘 판단해야 한다.

--

APIKEY

-> DB 조회를 해야 함.

-> 인증을 확인할 때.

 

JWT

->DB 조회 안 함.

-->apiKey에 비해 속도가 빨라짐

->토큰 확인을 처리.

 

---

스프링 시큐리티의 인증 정보 저장 방식

-> 세가지만 요구

-username, password, authorities