영속성

: 사라지지 않고 계속해서 접근 가능한 속성

@Transactional

-> 쓰기 지연을 통해서 데이터의 반영을 늦추는 어노테이션
-> 각각의 Entity의 save메서드가 발동할떄마다 값을 저장하는 것이 아니라 실제로 메서드가 완전히 종료된다면 그떄에 값을 DB에 저장을 하는 어노테이션
쉽게 말해 값을 한번에 모아서 저장을 한다.
-> 하지만 만약 @Transactional을 지정하지 않는다면 save할떄마다 값이 DB에 저장이 된다.
-> 만약 checkedException(Exception)이 발생하게 되었을 경우에는 값이 저장되지만
이 외의 예외(RuntimeException 등등)은 값이 저장되지 않는다.

• Exception같은 경우에는 최상위 클래스 이기 떄문에 개발자가 스스로 처리하라고
  프로그램이 지정하기 떄문에 예외가 된다.
  
  이와 같이 지정하면 값이 한번에 저장된다.
  
  이와 값이 설정하지 않는다면 save메서드가 입력될떄마다 값이 저장된다.

이처럼 RuntimeException발생시에는 값이 저장되지 않는다. == 롤백

Exception예외의 경우에는 값이 롤백 되지 않지만 따로 @Transactional에 코드를 입력해주면
Exception이어도 값이 롤백 된다
== 저장이 안된다.

-> 실수가 가장 많은 부분으로 다른 메서드를 통해서 @Transactional이 붙은 메서드를 실행하게 된다면

실제 실행시에는 @Transactional이 적용되지 않는다.
-> 무시 된다.

DB가 여러개 있다면 각각 DB정보는 별도의 공간을 구성한다.
-> mysql의 영역에서 DB의 값이 수정이 되어도
-> H2에서는 값이 수정 되지 않는다.

하지만 모든 메서드가 종료되고 mysql의 값을
commit하게 된다면 결과값은 동일하게 바뀐다

@Transactional(isolation = Isolation.READ_UNCOMITTED)
로 선언하고 중간에 값을 바꾸면 바로바로 값이 바뀌게 된다.
-> 반드시 commit 해주어야 한다
-> 중간에 값을 수정하여 혼동을 줄수 있기 떄문에 실제로는 많이 사용 되지 않는다.

오히려 commit한 정보만을 받아오겠다는
@Transactional(isolation = Isolation.READ_COMITTED)
어노테이션을 많이 사용한다.

@Transactional(isolation = Isolation.REPEATABLE_READ)
-> 고유의 값을 그대로 유지하는것
-> A,B 데이터 영역이 있다고 할떄 B데이터 영역에서는 데이터를 수정한다.
-> 그후 commit 하여 데이터를 전송하게 되면 A에 영향을 주게 되지만
-> 어노테이션을 저렇게 적용하면 A 고유의 값으로 계속해서 진행되고
-> 이후 TEST가 종료가 되게 된다면 B가 전송된 값이 A를 수정한다.

[interface] EntityManager
-> 영속성에 대해서 가장 주체적으로 접근을 할수가 있는 인터페이스
-> 영속성을 부여할지 안할지에 대해서 관리할수 있다.

=======================**===================
이 외에도 @Transactional에는 다양한 사용법이 있다.
하지만 너무 방대하고 구체적인 사용법이기 떄문에 후에 필요성이 느껴지면 추가적으로 작성을 해볼것이며
이 부분은 실제로 사용이 자주 되는 부분에 대해서만 기록을하였다.