전체 글 5

Spring ChainedTransactionManager(@Transactional)

데이터 무결성을 보장하기 위해 트랜잭션을 사용하곤 한다. Spring에서 트랜잭션 매니저를 이용하여 트랜잭션을 사용할 수 있는데 @Transactional이라는 어노테이션이 지정된 함수에서 예상치 못한 Exception이 발생되었을 때 트랜잭션 매니저가 알아서 데이터를 롤백을 진행해준다. 그러나.. 데이터소스가 2개고 트랜잭션 매니저가 2개일 때는 혼란을 가져온다. 다중 트랜잭션 처리를 위해 Spring에서는 chainedTransactionManager라는 구현체를 제공해준다. 이와 같이 2개의 데이터소스 laPublic과 seed를 같이 사용할 수 있다. - ChainedTransactionManager로 묶이는 각 트랜잭션이 Connection pool의 min/max 개수는 동일하게 지정해야 한다..

카테고리 없음 2020.03.20

Slack bot 연동

특정 데이터에 대한 모니터링 알람 배치를 설정해놓았다. 오전 9시에서 12시까지 한 시간 단위로 모니터링을 설정해 놓았고, 12시 이후에 모니터링을 확인하려면 직접 DB로 확인해보는 수밖에 없었다. 이러한 불편한 점을 개선하기 위해 모니터링을 받는 것이 아닌 실시간으로 확인할 수 있는 방법을 생각해봤는데, bot을 연동하면 적합하다는 생각을 하여 slack봇을 통해 실시간 모니터링을 하기로 결정을 하였다. 우선, 경량화된 서버를 빠르게 설정하고 개발하기 위해서 언어는 node.js를 사용하기로 하였다. Node Slack SDK -> https://slack.dev/node-slack-sdk/ Slack | Node Slack SDK The Slack platform offers several APIs ..

카테고리 없음 2020.02.16

get요청 Request Entity Too Large 원인

원인 get으로 요청 시 서버가 허용하도록 구성된 값보다 클 경우 413 오류가 발생한다. 보통 용량이 큰 파일을 업로드할 때 발생하지만, 나의 경우에는 GET 요청 시 parameter 값들이 너무 많아 허용 값을 초과 한 경우이다. (URL 6400Byte..) 해결 웬만하면 서버의 설정값을 변경하는 것보단 application을 수정하는 것이 낫다고 생각하였고, 결정을 내린 방법은 GET 요청을 POST로 변경하는 방법이었다. POST 방식은 body에 데이터들이 동봉되어 전송되기 때문에 get보다는 많은 데이터를 전송할 수 있기 때문이다. 또한, 나의 경우에는 Limit 허용 값들을 서버에 따로 설정을 하지 않아도 된다는 가장 큰 이유가 있었다. * 참고 GET - 데이터를 Header에 포함하여..

카테고리 없음 2020.01.22

[DBCP] isValid() returned false

DBCP (isValid() returned false) DB connection 시 연결의 유효성을 검사한다. 연결이 유효하면 true이고, 연결이 유효하지 않거나 제한 시간이 만료되기 전에 연결의 유효성을 확인할 수 없으면 false를 return 한다. 문제 발생 - 하루에 한 번 특정 시간에 실행이 되는 배치가 있었는데, 항상 배치가 실행될 때 isvalid() return false를 여러 번 return 후 connection이 맺어지는 현상이 발생. 원인 - SHOW VARIABLES LIKE '%timeout' 확인해본 결과 wait_timeout이 28800초(8시간)로 설정되어 있었고, 28800초 이후 커넥션이 끊기고 배치가 실행 되면서 connection을 다시 맺을때 isValid..

카테고리 없음 2020.01.14