2019/11

findAll로 다 가져와서 앱에서 필터링? 아니면 쿼리 WHERE절에서 필터링? 어디서 관리하는게 더 나은가? PagingItemReader 같이 offset 기반으로 분할해서 읽어오는 경우, 일단 다 가져와서 앱에서 필터링하게 되면 update로 인한 offset이 틀어짐이 발생 할 수 있다. 전제 작업 A1 read 대상 항목 : complete=n & type=A 작업 B1 read 대상 항목 : complete=n & type=B 작업 A1, B1에서는 read 대상 항목을 임시 테이블에 적재 작업 A2, B2에서는 임시 테이블에서 대상 가져와 complete=y로 update 작업 {}1, {}2는 다른 Step으로 되어 있음. (Chunk 단위 처리 아님) 같은 Step으로 구성하고 read..

tomcat 설치 ```bash # java 먼저 설치하고, JAVA_HOME 환경변수 설정. $ brew search tomcat $ brew install tomcat $ /usr/local/Cellar/tomcat@8/8.5.49/bin/catalina configtest # 확인 차 $ /usr/local/Cellar/tomcat@8/8.5.49/bin/catalina start # localhost:8080 접속해서 잘 뜨나 확인 $ /usr/local/Cellar/tomcat@8/8.5.49/bin/catalina stop ``` IntelliJ 연동 Run - Edit Configurations... Tomcat Server 항목 추가 Tomcat Home 경로는 `` /usr/local/C..

지엽적인 성능 개선에 집착하지 마라 리팩터링 하다 보면, 예를 들어 반복문을 분리면서 같은 인덱스로 반복을 2번 돌게되는 경우 같은, 성능 관점에서 비효율적인 코드를 종종 마주치게 된다. 그 때 읽어보면 좋은 글. 무엇보다도 반복문을 쪼개서 성능이 느려지지 않을까 걱정할 수 있다. 이처럼 반복문이 중복되는 것을 꺼리는 이들이 많지만, 이 정도 중복은 성능에 미치는 영향이 미미할 때가 많다. ... 경험 많은 프로그래머조차 코드의 실제 성능을 정확히 예측하지 못한다. 똑똑한 컴파일러들은 최신 캐싱 기법 등으로 무장하고 있어서 우리의 직관을 초월하는 결과를 내어주기 때문이다. 또한 소프트웨어 성능은 대체로 코드의 몇몇 작은 부분에 의해 결정되므로 그 외의 부분은 수정한다고 해도 성능 차이를 체감할 수 없다...