기록들 https://github.com/ndgndg91

이번글에서는 @Transactional propagation 에 대해서 정리해보겠다. 그 전에 트랜잭션 관리 방법에 대해서 간단하게 정리하겠다. Application 을 개발할 때, Transaction 관리를 두 가지중 선택할 수 있다. 1. Programmatic Transaction Management 2. Declarative Transaction Management Programmatic Transaction Management 는 말 그대로 Transaction 관리를 코드로 직접 구현한다. Declarative Transaction Management 는 해석하면 선언적 트랜잭션 관리이다. 흔히 Spring framework 를 사용할 때 설정을 해주며 트랜잭션이 필요한 비즈니스 로직을 구현할 때 @Transactional 어노테이션을 사용한다. 위에서 rollback 과 commit 을 코드로 관리하는 반면,  AOP 를 통해서 관리된다. 따라서 보다 비즈니스 로직에 집중할 수 있다. Programmatic transaction management Vs Declarative transaction management Programmatic transaction management 는 보통 transaction 의 수가 적을 때 적합한 방식이다. 예를 들어, 자원에 대한 update operation 단지 몇 가지일 경우이다. transaction proxies 설정을 원하지 않을 때 적합하다. 이러한 경우에, TransactionTemplate 을 사용하는 것이 좋다. 반대로, application 이 수많은 transaction operation 이 필요할 경우, Declarative transaction management 가 더 적합하다. 이는 business logic 과 transaction management 을 분리시켜 주며, 설정 또한 그리 어렵지 않다. Spring framework 를 사용할 때, transaction ma...

Spring과 Spring Boot 의 가장 큰 차이점은 @SpringBootApplication Annotation 의 초기 설정 부트스트래핑이지 않을까 생각한다.  Spring initializer(https://start.spring.io/) 를 통해서 프로젝트를 생성하면, 아래와 같이 main 메서드를 가진 class 와 @SpringBootApplication Annotation 을 확인할 수 있다. 그렇다면, 정확히 @SprinBootApplication 이 하는일은 무엇일까? @SpringBootConfiguration, @EnableAutoConfiguration, @ComponentScan 3가지 어노테이션들을 확인할 수 있다. 그렇다면 각 3가지 Annotation 역할은 무엇일까? @EnableAutoConfiguration : Spring Boot 의 auto-configuration 메카니즘을 가능하게 한다. @ComponentScan : application 이 위치한 package 에 대하여 @Component scan 을 가능하게 한다. @SpringBootConfiguration : context 에 추가적인 spring beans (@Bean 어노테이션을 통해서 정의된 메서드를 가진 클래스) 등록을 가능하게 하며, 추가적인 configuration class 들을 import 할 수 있다.  그렇다면 auto-configuration 메카니즘은 무엇일까? Spring Boot 는 maven 혹은 gradle 에 추가된 jar dependencies 를 바탕으로 자동으로 설정을 시도한다. 예를 들어, HSQLDB 가  classpath 에 있다면, 수동으로 database connection beans 들을 설정할 필요가 없다. Spring Boot 는 자동으로 in-memory database 설정을 해준다. 단지, @EnableAutoConfiguration 이 포함된 @SpringBootAp...

 객체 지향의 5대 원칙으로 불리는 SOLID 원칙에 대해서 예제를 만들어서 정리해보려고 한다. SOLID 를 처음 알게 된 것은 첫 회사 면접에서 질문을 통해서 알게 되었다.  "객체 지향의 5대 원칙에 대해서 아나요?" 라는 질문이다. 벌써 3년 전 일이다. 당시에는 "응? 그런게 있구나??" 속으로 생각했었다. 면접이 끝나고 찾아봤는데, 그 당시에는 이게 개발하는데 중요한 것일까? 라는 생각을 했었는데 1년 씩 연차가 쌓이고 경험을 하면서 음 그래서 중요하구나.. 로 바뀌게 되었다. 코드를 한 번 작성하면 끝나는 것이 아니라, 결국 유지 보수를 해야된다. Software 는 계속해서 변화하는 요구사항들을 만족시키기 위해서 진화해야 된다. 그래서 중요한 것은 재사용하기 쉽고, 확장하기 쉽고, 진화하기 쉽고, 테스트하기 쉬워야 한다.  따라서 좋은 코드를 작성하기 위해서 스스로 정리 한다. 1. Single Responsibility Principle - 단일 책임 원칙 A class should have a single responsibility. 클래스는 책임을 하나만 가져야 한다. 다시 말해, 클래스 변경의 이유는 오직 하나여야만 한다. 왜? 1. Testing - 책임이 적을수록 테스트 케이스도 적어진다. 2. Lower Coupling - 책임이 적으면, 클래스의 기능도 적어지고, 의존성도 낮아진다. 그렇다면 예제를 통해 확인해보자. God 클래스를 만들었다. 이름에서 알 수 있듯이 많은 일을 하는 클래스이다. God 은 design 하고 develop 도 하고 plan 도 하고 customer service 도 한다. 흔히들 말하는 common 의 저주이다. God 은 모든일을 할 수 있다. 그럼 SRP 에 맞게 Class 를 나눠보자. God 클래스를 총 4개의 class 로 나누었다. Developer, Designer, Planner, CustomerServiceRepresentative.  준비한 예제가 ...

Index 종류 B-tree - high cardinality, re-balanced needed, logN Hash - Hash Function BitMap - low cardinality columns ( ex. boolean ) Specialized Index Index Pros and Cons index 는 항상 모든 케이스에 적절한것은 아니다. 적은 수의 rows 의 table 의 경우 index search 보다 순차적 search 가 빠를 수 있다. 또한 table 의 대부분의 rows 나 전체 rows 를 조회할 때는 순차적 search 가 더 빠를 수 있다. 그러나, 대부분의 경우 index 가 조회 성능을 향상 시킨다. Where 절을 통한 쿼리 Index 에 해당하지 않는 행은 검색에서 제외한다. Join 에서도 성능이 좋다 min, max 값을 찾기 좋다. group by, order by 의 성능에도 좋다. table 에서 직접 조회하기 보다, index 를 통해서 조회한다. index 는 SELECT query 의 속도를 높여주는데 좋은 반면에, 실질적으로 UPDATE, INSERT, DELETE 는 속도를 저하 시킨다. 왜냐하면 MySQL 은 table 에 변화가 일어나면 data 를 reindex 한다. 만약, 조회보다 변경이 많은 테이블에서는 인덱스를 사용하지 않는 것이 좋을 수도 있다. 또한 색인은 저장해야하는 추가 데이터가 있는 테이블로 데이터베이스에서 추가 공간을 차지한다는 점도 고려해야한다. 이는 큰 고려 사항은 아니지만 데이터베이스에 허용하는 공간에 따라 달라질 수 있다. Clustered Index vs Non-Clustered Index Clustered Index  - PK 제약 조건과 같이 생성된 테이블은 database engine 이 자동으로 clustered index 를 생성한다. 따라서 data 는 key, value 에 맞게 정렬되어 저장된다. Non-Cluster...