redis O(n) 명령어

KEYS : 패턴에 일치하는 모든 키를 반환

-> 최적화 방향 : 한꺼번에 다 가져오는게 아니라 순회 할 수 있도록 scan 명령 사용,

-> 그 사이사이에 다른 커맨드를 처리할 수 있어서 long blocking 방지

-> ex) scan 0

FLUSHALL : 레디스 서버의 모든 데이터(key,value)를 삭제한다.
FLUSHDB : 현재 선택한 DB의 모든 데이터(key,value)를 삭제한다.
-> async 시 별도의 쓰레드에서 background로 삭제하여 long blocking 방지

Delete Collections
Get All Collections
-> Collection은 너무 크게 유지 하지 않는것이 좋음, 하나당 몇천개 안쪽으로만..

"자동 커밋이 설정된 채 커밋할 수 없습니다"
"Could not commit with auto-commit set on"
commit 뿐 아니라 rollback도 마찬가지입니다.

고객사에서 Oracle을 업데이트하며 갑작이 위와같은 에러가 발생한다곤 합니다...

(과거 Oraccle JDBC Driver에서는 발생하지 않았지만... )
이전에는 엔진 코드를 다 변경해주기도 했지만..
지금까지 최근 Oracle에서만 발생하는 에러로 모든 commit과 rollback을 수정하는건 참 낭비스러운 작업입니다.

그래도 코드를 수정하지 않고도 해결할 수 있도록 Oracle에서도 호환성을 맞춰주기 위해 JVM 옵션을 하나 제공합니다.

-Doracle.jdbc.autoCommitSpecCompliant=false

docs.oracle.com/database/121/JAJDB/oracle/jdbc/OracleConnection.html#CONNECTION_PROPERTY_AUTO_COMMIT_SPEC_COMPLIANT

물론 가이드한다고 고객사가 이 옵션을 설정을 해서 해결한다는 보장은 없지만.. 
일단 옵션은 있습니다..

주로 업무상 디비 락이 필요한경우 Select for update를 주로 활용했는데
optimistic lock을 JPA에서 편리하게 사용할수 있게 지원하고 있어
테스트를 하며 정리해봤습니다.
(@Version이 있고 없고, 변경사항이 있을때 어떤 쿼리가 발생하는지 등)

작성한 github 위치 : https://github.com/Meteorkor/JPA_Study/edit/master/docs/LockType.md

테스트 코드는 추후 정리해서 업로드 예정입니다.

LockModeType

• OPTIMISTIC

  • 트랜잭션 중 변경사항이 있을때
    • SELECT : 이때 버전을 같이 가져옴(해당 필드에 @Version, org.springframework.data.annotation.Version 가 아니라 javax.persistence.Version)
    • UPDATE : 이때 앞에서 Select한 version을 where에, set절에는 version=version+1 으로 version 업데이트
      • UPDATE 된 값이 없으면 중간에 버전이 변경된것으로 파악하여 에러 발생
  • 트랜잭션 중 변경사항이 없을때
    • SELECT : 이때 버전을 같이 가져옴(해당 필드에 @Version, org.springframework.data.annotation.Version 가 아니라 javax.persistence.Version)
    • SELECT : 이때 앞에서 Select한 version을 where에, 조회된 결과가 없으면 에러 발생
  • 수정을 하게 되면 version은 한개씩 올라감, 수정을 하지 않으면 version은 올라가지 않음

• OPTIMISTIC_FORCE_INCREMENT

  • 트랜잭션 중 변경사항이 있을때
    • SELECT : 이때 버전을 같이 가져옴(해당 필드에 @Version, org.springframework.data.annotation.Version 가 아니라 javax.persistence.Version)
    • UPDATE : 이때 앞에서 Select한 version을 where에, set절에는 version=version+1 으로 version 업데이트
      • UPDATE 된 값이 없으면 중간에 버전이 변경된것으로 파악하여 에러 발생
    • UPDATE : Version을 한번 더 업데이트
  • 트랜잭션 중 변경사항이 없을때
    • SELECT : 이때 버전을 같이 가져옴(해당 필드에 @Version, org.springframework.data.annotation.Version 가 아니라 javax.persistence.Version)
    • UPDATE : Version을 업데이트
  • 수정을 하게 되면 version은 두개씩 올라감
  • 수정을 하지 않으면 version은 한개씩 올라감

• READ(OPTIMISETIC과 동작 같음)

• WRITE(OPTIMISTIC_FORCE_INCREMENT 과 동작 같음)

• PESSIMISTIC_READ

  • @Version이 없는 경우
    • 트랜잭션 중 변경사항이 없을때
      • SELECT FOR UPDATE
    • 트랜잭션 중 변경사항이 있을때
      • SELECT FOR UPDATE - UPDATE
  • @Version이 있는 경우
    • 트랜잭션 중 변경사항이 없을때
      • SELECT FOR UPDATE
    • 트랜잭션 중 변경사항이 있을때
      • SELECT FOR UPDATE - UPDATE(version도 함께 올라감)

• PESSIMISTIC_WRITE

  • @Version이 없는 경우
    • 트랜잭션 중 변경사항이 없을때
      • SELECT FOR UPDATE
    • 트랜잭션 중 변경사항이 있을때
      • SELECT FOR UPDATE - UPDATE
  • @Version이 있는 경우
    • 트랜잭션 중 변경사항이 없을때
      • SELECT FOR UPDATE
    • 트랜잭션 중 변경사항이 있을때
      • SELECT FOR UPDATE - UPDATE(version도 함께 올라감)

• PESSIMISTIC_FORCE_INCREMENT

  • @Version이 없는 경우
    • 에러 발생
  • @Version이 있는 경우
    • 트랜잭션 중 변경사항이 없을때
      • SELECT FOR UPDATE - update version
    • 트랜잭션 중 변경사항이 있을때
      • SELECT FOR UPDATE - update version - updateUPDATE(version도 함께 올라감)

• NONE

20.07.16

글 작성 방법을 조금 변경하려고 합니다.

업무중 소스를 까보며 혹은 책이나 로컬로 테스트를 하며 하나씩 정리해서 글을 작성하곤 했는데

아무래도 글을 작성하기 위해 쓴 코드들은 대부분 버려지다 보니

아쉬움이 있어서 github에 repo를 하나씩 파서 샘플들을 작성하며 README와 글을 작성하려고 합니다

(README와 글이 동일 할 수도 있고, 조금 더 풀어서 작성할 수 있을수도 있을것 같습니다)

해당 글의 Repo는

https://github.com/Meteorkor/Stream-Study

스트림, 데이터의 흐름

• 배열 또는 컬렉션, 또는 여러개의 조합으로 가공 및 필터링을 수행할 수 있도록 기능 제공

• for, foreach에 비해 코드 복잡도를 줄일 수 있음

• 람다를 활용하여 코드의 양을 줄이고 간결하게 표현 가능

• 간단하게 병렬처리 가능(parallel())

• primitive의 경우 IntStream이나 LongStream을 사용하지 않는다면, Boxing으로 인해 성능 저하가 발생할 수 있으니 주의 필요

Stream 생성

• Array, Collection
• Stream
  • Stream.builder()
  • Stream.of()
  • Stream.empty()
  • Stream.generate()
  • Stream.iterate()
    • (final T seed, final UnaryOperator f)
    • (T seed, Predicate<? super T> hasNext, UnaryOperator next)
      • JDK9
  • Stream.concat()
• 기본타입(IntStream, LongStream), String, 파일 스트림(BytesReader)
• 병렬스트림
• StreamSupport(추후)

가공(transformer)

• Filtering
• Mapping
• Sorting
• Iterating

결과(terminal)

• Calculating
• Reduction
• Collecting
• Matching
• Iterating

주의 사항

• primitive

  • primitive 타입을 boxed 된 Stream을 사용하게 된다면 boxing unboxing이 반복되어 나타날수 있음
  • 필요에 따라 IntStream, LongStream, DoubleStream 을 잘 구분하여 사용할것
    • mapToInt, mapToLong, mapToDouble 도 마찬가지

• 병렬 스트림

  • 메인 스레드 혹은 일반 스레드에서 parallel()의 경우 ForkJoinPool.common을 사용
    • ForkJoinPool.commonPool()은 보통 Runtime.getRuntime().availableProcessors() 만큼의 스레드를 가지고 있음
    • 다른 각각 스레드에서 parallel()을 사용하는 경우에도 같은 ForkJoinPool.commonPool() 공유해서 사용하기 때문에 Blocking 작업으로 인해 전체적으로 성능이 떨어질수 있음
      • 방지하기 위해서는 ForkJoinPool을 신규로 만들고 신규로 만든 ForkJoinPool에 submit을 하면 ForkJoinPool.commonPool() 이 아닌 신규로 만든 Pool에서 병렬처리로 동작

• 파이프라이닝

  • Stream은 하나의 데이터를 파이프라이닝 방식으로 처리
    • {A,B,C}.map(변환1).map(변환2)... 를 수행할때, A,B,C 변환1 을 수행하는것이 아니라 A에 대해 변환1, 변환2, B에 대해 변환1, 변환2 방식으로 동작
      • 물론 병렬의 경우 이 작업들을 서로 다른 스레드에서 처리 할 수 있음
  • 흐름 정의에 따라 처리내용이 수행되지 않을 수 있음
    • {A,B,C}.peek().map().count() 의 경우 peek와 map이 count()에 영향을 주지 않기 때문에 동작하지 않을 수 있음
      • unit-test에서는 동작하지 않았으나 travis-ci에서는 동작하던...
    • {A,B,C}.peek().map() , terminal(결과처리들, calc, reduce, collect 등) 호출이 없을 경우 결국 peek나 map나 의미가 없기 때문에 수행되지 않음