스프링 프로젝트 - java-ims

Mockito를 통한 Service 단위테스트와 도메인 단위테스트

• 다른 의미의 테스트임 : 같아보이지만 Service 계층을 테스트 하는 것과 도메인에 대한 단독 테스트는 다름
  • 서버 자원을 사용하는 것과 일반 자바 객체를 테스트 하는 것에서 차이

삭제 기능

• 바로 삭제를 하지않고, 삭제 상태로 만들어놓음 : 삭제 상태로 변경된 엔티티를 또다른 엔티티(히스토리)로 만들어서 보관함
  • 일정 기간이 지났을 때 엔티티를 실제로 삭제함
  • 기록 또한 일정기간 보관

@Entity
public class DeleteHistory {
    
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTIFY)
    private long id;
    
    @Enumerated(STRING)
    private ContentType contentType;
    
    private long contentId;  
    
    @ManyToOne
    @JoinColumn(foreignKey = @ForeignKey(name = "fk_deletehistory_to_user"))
    private User deletedBy;
    
    private LocalDateTime deleteTime;
}

서버사이드 랜더링 할 때 결과에 따라 분기 처리를 할 때

• Result 객체를 사용함 : 서버사이드랜더링 해야하기때문에, 서비스 단에서 처리 이후 컨트롤러에 결과를 넘겨줄 때 Result를 넘겨줌
  • Result에 따라 컨트롤러가 처리를 하는데, Result에는 ok() / fail()에 따라서 가지고 있는 데이터가 다름

jvm memory

jvm 런타임 데이터 영역

• 운영체제로부터 할당받은 메모리를 가지고 데이터를 저장하는 영역 : 메모리 영역을 분할해서 저장하고 관리
  • 자체적으로 메모리 관리 : 프로그램 안에서 프로그램을 실행시키는 것이 jvm(java virtual machine)
  • 효율을 위해 GC(Garvage Collector)가 활동함 : 사용되지않는 힙 영역의 메모리를 회수함(스택과 연결되지않은 힙 자원)

런타임 데이터 영역 분할 관리

• 총 6개의 영역이 나뉘어짐 : 최우선적으로 알아야할 영역 - 메소드(class, static) / 힙 / 스택 영역
• 핵심 3가지 영역
  • 메소드 : jvm 시작 시 생성되는 영역, 클래스와 인터페이스의 런타임 상수풀(static, 필드 메소드의 참조 주소 값이 저장), 메소드 선언(정보)과 실행 바이트코드 정보가 담기며, 쓰레드 간 공유하는 영역(간략히 정의하면 클래스, 인터페이스의 정보가 담김)
  • 힙 : 객체(인스턴스)가 저장되는 공간이며, 쓰레드 간에 공유되는 영역임(공유 객체 조심), GC의 메모리 회수 대상
  • 스택 : 스택 프레임(메소드의 실행에 필요한 정보 - 지역변수 배열과 피연산자 스택)을 저장하는 구조체(스택), 메소드 실행 시 스택 프레임이 생성되어서 push되고, 메소드 실행이 종료되면 스택프레임이 스택에서 pop 됨, 쓰레드마다 할당되는 영역

JPA - 엔티티, 엔티티 매니져, 엔티티 매니져 팩토리, 커넥션풀, 커넥션, 영속성 컨텍스트

• 엔티티 : 데이터베이스의 레코드라고 생각하면 됨, 데이터의 단위(1개), 엔티티를 Object화 하기위해서 클래스를 만듬(엔티티 클래스)
  • 생명주기 : 준영속(메모리에만 존재) - 영속(영속성 컨텍스트에 저장, 관리, 데이터베이스 싱크) - 준영속(더이상 영속성 컨텍스트에서 관리X) - 삭제(삭제된 상태)
• 엔티티 매니져 : 엔티티를 CRUD 하는 관리자 역할, 쓰레드 간 공유해서는 안됨, 데이터베이스 연결이 필요한 시점까지 커넥션 풀에서 커넥션을 꺼내지않음
  • 코드에서 만드는 Repository가 엔티티 매니져
• 엔티티 매니져 팩토리 : 엔티티 매니져를 생성하는 팩토리, 쓰레드 세이프함, 데이터베이스 연결에 필요한 커넥션들이 담긴 커넥션 풀을 생성함
  • 커넥션 : 데이터베이스 연결 정보를 가지고 있음, 쿼리를 실행하기위해서 데이터베이스와 연결하고, 쿼리 실행까지 해야함
• 영속성 컨텍스트 : 바로 데이터베이스에 쿼리를 날리지않고, 영속성 컨텍스트라는 중간 계층을 거치도록 함, 중간 계층을 둠으로써 이점이 있음, 어플리케이션 메모리 사용(하나의 엔티티 매니져에 하나의 영속성 컨텍스트가 생성됨)
  • 1차 캐시, 동일성 보장 : 트랜잭션에서 조회한 엔티티를 캐시해둠 -> 동일 객체 리턴할 수 있게 됨
  • 트랜잭션 지원 지연쓰기 SQL 저장소 : 트랜잭션의 모든 작업을 처리 후 성공했을 때 한번에 SQL을 날리는데, 작업 마다 SQL을 생성해서 영속성 컨텍스트 내부에 저장소에 SQL을 저장해뒀다가 SQL을 한꺼번에 처리
  • 변경 감지 : 트랜잭션에서 조회한 엔티티가 변경되면 감지를 하고 UPDATE 쿼리를 만들고 데이터베이스에 날림