Spring Boot Auto Configuration 예제를 보다가 maven은 많은데 나한테 익숙한 gradle의 예제는 몇 개 안되어서 gradle로 한 번 만들어 보았다.

  1. contact-spring-boot-starter 프로젝트를 clone후에 build 한다.
    • 만든 jar파일을 어떻게 dependency를 추가해야 할까 잠시 고민했는데 maven local repository를 사용하면 간단했다.
  2. gradle install로 jar파일을 local repository에 올린다.
    • maven plugin을 추가하면 gradle install로 local repository에 올라간다.
    • maven local은 내 계정 폴더에 .m2 폴더이다.
    • 같은 버전으로 install을 계속하다 보면 갱신이 안될 수도 있다. 그럴 때는 .m2폴더를 지워야 할 때도 있었다.
  3. AutoConfigurationTest 프로젝트를 clone후에 build 한다.
  4. gradle bootrun으로 실행한다.
  5. AppConfig에 MyContact Bean을 생성한 것과 안 한 것과의 차이를 확인해 본다.
    • @ConditionalOnMissingBean에 의해서 MyContact를 만들면 만들어진 bean의 내용이 나오고 MyContact bean이 없다면 properties의 내용이 나온다.

'Programming > Spring Framework' 카테고리의 다른 글

2way ssl 인증을 위한 JKS 만들기  (0) 2020.03.10
코딩 시험과 TDD  (0) 2019.02.14
Annotation-based Controller  (0) 2017.02.01

2020.04.15일자 DSM 판올림에 드디어 let's encrypt의 와일드카드 인증서가 지원되는군요!

이제는 cli를 이용해 따로 받을 필요 없이 DSM에서 바로 적용 가능 할 것 같습니다.

이것도 해봐야 겠습니다. (아직 만료 4주전이 아니라 안되겠지만...)

그보다 3개월 마다 자동 갱신 되도록 스케쥴도 원클릭으로 되면 좋을것 같은데....

 

DSM 6.2.3의 새로운 기능

  1. 씬 프로비저닝 LUN은 볼륨 공간이 부족할 때 보호되어 클라이언트가 LUN에 데이터를 쓰지 못하게하고 기존 데이터에 대한 읽기 전용 액세스를 허용합니다.
  2. 웹 포털 및 파일 프로토콜을 통해 도메인의 UPN (사용자 이름)을 사용하여 DSM에 로그인 할 수있는 지원이 추가되었습니다.
  3. 로컬 사용자 가져 오기를위한 비밀번호 변경 옵션을 지원합니다.
  4. 가져온 사용자 목록의 호환성이 향상되어 가져온 파일에 구문 오류가있을 때보다 명확한 오류 메시지를 제공합니다.
  5. 사용자가 선택한 SMB 전송 이벤트 만 기록하도록 지원을 추가하여 요구 사항을보다 밀접하게 충족시키는 전송 로그를 제공합니다.
  6. 클라이언트 사용자가 SMB 프로토콜을 통해 공유 폴더에서 하위 디렉토리의 변경 사항을 모니터링 할 수 있도록 지원이 추가되었습니다.
  7. 사용자가 적시에 응답 할 수 있도록 데스크탑 알림에 대한 세부 정보를 추가했습니다.
  8. 외부 UDF 파일 시스템 장치에 대한 지원이 추가되었습니다.
  9. 고 가용성 클러스터에서 Open vSwitch 옵션에 대한 지원이 추가되었습니다.
  10. IP 충돌 감지에 대한 지원을 추가하여 그에 따라 로그 및 알림을 제공합니다.
  11. 와일드 카드 인증서에 대한 Let 's Encrypt 지원이 추가되었습니다.
  12. 클라이언트의 IP 주소가 변경된 후 HTTPS 연결을 통해 DSM 로그인의 필요성을 다시 포기하는 지원이 추가되었습니다.
  13. ext4 볼륨의 Thick Provisioning LUN에 대한 하드웨어 지원 잠금 지원이 추가되었습니다.
  14. DSM 로그인 페이지에서 사용자 정의 바닥 글 메시지 지원이 추가되었습니다.

https://www.synology.com/ko-kr/releaseNote/DS415+

 

DS415+ Release Notes | Synology Inc.

Version: 6.2.3-25426 (2020-05-13) Important Note The update is expected to be available for all regions within the next few weeks, although the time of release in each region may vary slightly. If you want to update to the latest version now, please go to

www.synology.com


2020.05.15

부푼 마음을 부여잡고 와일드카드 인증서를 발급 받아볼까 하고 진행하는데.....

Synology DDNS에서만 사용가능?!?!?!

결국 개인 도메인은 안되는 걸로 판명....

아쉽지만 저는 기존의 certbot을 사용하여 발급받는 방법을 써야 할 것 같습니다....ㅠㅠ

isolation level이란 트랜잭션에서 일관성이 없는 데이터를 어디까지 허용하는 수준

트랜잭션에서 일관성이 없는 데이터를 허용하도록 하는 수준을 Isolation Level이라고 합니다. 예를 들어, 한 사용자가 어떠한 데이터를 수정하고 있는 경우 다른 사용자들이 그 데이터에 접근하는 것을 차단함으로써 완전한 데이터만을 사용자들에게 제공하게 됩니다. 또한, 많은 사용자들의 수정 작업으로 인하여 통계 자료를 작성할 수 없는 사용자를 위하여 읽기 작업을 수행할 수 있도록 Isolation Level을 변경할 수 있습니다. 
Isolation Level을 조정하는 경우 동시성이 증가되는데 반해 데이터의 무결성에 문제가 발생할 수 있거나, 데이터의 무결성을 완벽하게 유지하는 데 반하여 동시성이 떨어질 수 있으므로 그 기능을 완벽하게 이해한 후에 사용해야 합니다.

 

@Transactional (isolation = Isolation.DEFAULT | READ_COMMITTED | READ_UNCOMMITTED | REPEATABLE_READ | SERIALIZABLE)

 

다음은 MySQL에서 지원하는 네 종류의 Transaction Isolation Level입니다.

READ UNCOMMITTED

  • COMMIT 되지 않은 데이터에 다른 트랜잭션에서 접근할수 있다.
  • INSERT, UPDATE, DELETE 후 COMMIT 이나 ROLLBACK에 상관없이 현재의 데이터를 읽어온다.
  • ROLLBACK이 될 데이터도 읽어올 수 있으므로 주의가 필요하다.
  • LOCK이 발생하지 않는다.

READ COMMIITED

  • Oracle DBMS의 경우 Default LEVEL이다.
  • COMMIT 된 데이터에 다른 트랜잭션에서 접근할 수 있다.
  • 구현 방식이 차이 때문에 Query를 수행한 시점의 데이터와 정확하게 일치하지 않을 수 있다.
  • LOCK이 발생하지 않는다.
  • MySQL에서 많은 양의 데이터를 복제하거나 이동할 때 이 LEVEL을 추천한다.

REPEATABLE READ

  • MySQL InnoDB의 경우 Default LEVEL이다.
  • SELECT시 현재 시점의 스냅샷을 만들고 스냅샷을 조회한다.
  • 동일 트랜잭션 내에서 일관성을 보장한다.
  • record lock과 gap lock이 발생한다.
  • CREATE SELECT, INSERT SELECT시 lock이 발생한다.

SERIALIZE

  • 가장 강력한 LEVEL이다.
  • SELECT 문에 사용하는 모든 테이블에 shared lock이 발생한다.

위의 Transaction Isolation Level 은 Read Uncommited 에서 Serializable  순으로 Concurrency 는 높아지고 속도는 느려진다. 따라서 이 둘의 균형을 잘 맞추는 것이 중요합니다.

Isolation Level  에 따라 나타나는 현상이 세가지가 있습니다.

  • Dirty Read
    • 어떤 트랜잭션에서 아직 실행이 끝난지 않은 다른 트랜잭션에 의한 변경 사항을 보게 되는 되는 경우를 dirty read 라고 합니다. 만약 원래 트랜잭션에서 그 변경 사항을 롤백하면 그 데이터를 읽은 트랜잭션은 dirty 데이터를 가지고 있다고 말합니다.
  • Repeatable Read
    • 어떤 트랜잭션에서 같은 질의를 사용했을 때 질의를 아무리 여러번 해도 그리고 다른 트랜잭션에서 아무리 여러 번 그 행을 변경해도 항상 같은 데이터만 읽어드리는 경우를 repeatable read 라고 합니다. 즉 repeatable read 가 요구되는 트랜잭션에서는 다른 트랜잭션에 의한 변경 사항을 볼 수가 없습니다. 그러한 변경 사항을 보고 싶으면 어플리케이션에서 트랜잭션을 새로 시작해야 합니다.
  • Phantom read
    • phantom read 는 다른 트랜잭션에 의한 변경 사항으로 인해 현재 사용 중인 트랜잭션의 WHERE 절의 조건에 맞는 새로운 행이 생길 수 있는 경우에 관한 것입니다. 예를 들어, 잔고가 $100 미만인 계좌를 모두 찾아내는 트랜잭션이 있고, 이 트랜잭션에서 그 데이터를 두 번 읽는다고 가정합시다. 처음 데이터를 읽어들이고 난 후에 다른 트랜잭션에서 잔고가 $0인 계좌를 새로 만들면 이 계좌도 잔고가 $100 이하라는 조건에 맞게 됩니다. 트랜잭션 격리 수준(Transaction Isolation Level)에서 phantom read 를 지원하면 새로운 “유령(phantom)”행이 나오지만 지원하지 않으면 새로 생긴 행을 볼 수 없습니다.
Isolation Level Dirty Read Nonrepeatable Read Phantom Read
READ UNCOMMITTED Permitted Permitted Permitted
READ COMMITTED Permitted Permitted
REPEATABLE READ Permitted
SERIALIZABLE

Tabel1. Ansi Isolation Levels

Mysql 의 InnoDB 스토리지 엔진의 기본 Isolation Level이 REPEATABLE-READ 이고 Oracle 은 READ-COMMITED 입니다. 각 DBMS별 isolation level 에 자세한 내용은 다음 링크에서 참조할 수 있습니다.

Oracle 은 READ-COMMITED 와 SERIALIZABLE 만 지원하며 나머지 두가지 isolation level  은 지원하지 않습니다.

isolation level 확인

mysql docker의 isolation level은 아래와 같습니다.

MySQL InnoDB의 Isolation LEVEL 문서

https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html

 

'Database' 카테고리의 다른 글

샤딩과 파티셔닝 개념 정리  (0) 2018.10.12
DB 정규화  (0) 2014.12.10

+ Recent posts