생각을 개발하자, 박진형

트랜잭션과 스프링 트랜잭션 격리성을 보장하면서도 성능을 가져가야함 동시에 실행되는 트랜잭션은 서로 영향을 미치면 안됨(상황에 따라 어느 수준까지 영향을 미치지 않을 것인가 정해야함 - Lock 정책) - 예를 들어 T1이 SELECT한 데이터를 T2가 UPDATE를 했을 때 T1이 다시 SELECT 하면 다른 값이 읽히는 그런 영향(Repeatable Read 불가 - 각 락 정책에 따라 발생할 수 있는 문제가 있음) 데이터 정합성 수준에 따라 Lock 정책을 정하면 됨 : 기본적으로 데이터베이스마다 설정되어있는 정책이 있음 mysql> show variables like 'tx_isolation';...

데이터 캐시하기(2) - 스프링 캐시 추상화, redis 글로벌 캐시 스프링 캐시 추상화 - AOP, 캐시 매니져 AOP : @Cacheable, @CacheEvict 캐시 관련 코드를 비즈니스 로직에서 덜어낼 수 있도록 어노테이션(포인트컷)을 설정해두면 프록시? CGLib? 어찌되었건 캐시 동작(read, write) @Cacheable : 캐시 서비스를 메소드 단위로 설정 어노테이션 name : 캐시 이름 메소드 파라미터(key), 리턴 데이터(value) : 파라미터가 없을 경우 기본 키 값을 생성, 파라미터가 여러개인 경우 key=”#파라미터명” 으로 설정, 객체일 경우 key=”#객체.필드명” (SpEL) @Cacheable("item") public Item findByName(String name)...

데이터 캐시하기(1) - 성능 차이보기 데이터 캐시의 필요성 : 고정적인 데이터나 매번 변경되지않아도 되는 데이터에 대해 DBMS에 매번 요청(Read)하지말고 캐시해둘 필요성이 있음 자바 캐시와 관련된 스펙 : JSP107(JCache) - API 표준(javax.cache) 캐시 제공 벤더에 상관없이 캐시할 수 있도록 만들어진 API : 캐시 쪽에서의 JDBC Map으로 구현 : key-value 캐시 스펙 구현체 : EhCache(JCache Provider) JSR : 자바 스펙에 추가된 기술에 대한 설명 공식 문서 캐시 종류 로컬 캐시 : 어플리케이션 내부 메모리 사용 글로벌 캐시...

오늘 하루 배운 것 부족한 부분은 정말 많다! 물론 이전에도 느꼈지만 면접보면서 부끄러운 순간이 정말 많았다 이정도까지 몰랐나싶을정도로…. 부족한 부분이 뭔지 알았으니깐 공부해야겠다 추상화한 프레임워크 사용한다고 정작 중요한 데이터베이스 경험이 그렇게나 없다니… 한참 멀었다는 생각 객체지향 개발자지만 서버 개발자임을 잊지말아야함 모든 것을 객체로 풀 수 있다는 생각보다 다른 지점에 해결점이 없나 생각해봐야함 경험이 부족하다는 탓보다 경험을 해보려고 노력하는 것이 중요함을 느끼게 됨 한단계 더 나아가려고 이미 건너온 길을 놓치고 있다는 생각이 들었음 면접 준비를 하면서.....

JPA, Spring lazy loading 실제 사용할 때까지 연관관계에 있는 객체를 실제로 데이터 찾고(커넥션) 초기화 하지않음 : 메모리를 아낄 수 있고, 커넥션을 하지않으니 효율적(쓸데 없이 테이블 JOIN을 하지않아도 되는 것임) 대신 원 타입을 상속받은 프록시 객체(가짜)가 할당되어있음 : 해당 객체를 처음 사용(최초 1회 - 메모리 상)하려고할 때 그제서야 데이터베이스에서 데이터를 찾고 객체 초기화를 함 컬렉션을 그대로 get받아도 초기화하지않다가 컬렉션.get(idx)를 할 떄 초기화 : 아래 예시를 보면 hibernate에서 만들어낸 컬렉션 이름이 나옴 - 쿼리도 여전히 날리지않음 영속성...