Will Of Rough

개요Spring Boot 로 JPA 서비스를 띄우면 시작 로그에 노란 경고가 한 줄 찍힌다, open-in-view 가 기본으로 켜져 있다는 그 경고다. 처음엔 이걸 끄면 컨트롤러에서 연관 객체를 꺼낼 때 예외가 나길래 그냥 켜 두는 게 편한 거 아닌가? 싶었다. 그런데 결제사 응답이 느려지던 날 DB 는 한가한데 커넥션 풀이 먼저 말라붙는 걸 보고, 이 설정이 — DB 연결을 응답이 나갈 때까지 쥐고 있게 만든다 — 는걸 알게되었다. 가끔씩 OSIV 글을 보면 "끄는 게 좋다" 하고 끝~인 경우가 많아, 왜 커넥션까지 묶이는지는 늘 아쉬운 부분이었다. 그렇기에 이번글은 OSIV 가 무엇을 열어 두는지부터 공부해보려고한다.영속성 컨텍스트의 수명 — 책상은 언제 치워지는가도서관에 가면 자리를 하나 잡고, ..

개요주문 서비스에 "주문이 저장되면 메일을 보내라" 같은 뒷일을 붙일 때, 처음엔 저장 메서드 끝에 메일 발송 한 줄을 그냥 넣었었다. 사실 이게 뭐가 문제인가 싶었다, 순서대로 실행되니 저장 다음에 메일이 가는 거 아닌가? 싶었는데 취소된 주문에도 메일이 날아가고 메일 서버가 죽자 주문까지 안 되는 걸 보고 — 뒷일은 도장이 찍힌 뒤에, 새 종이에 — 해야 한다는걸 알게되었다. 가끔씩 이벤트 리스너 글을 보면 어노테이션 붙이는 법만 있고 그 안에서 저장이 왜 사라지는지는 없이 끝~인 경우가 많아 늘 아쉬운 부분이었다. 그렇기에 이번글은 Spring 의 트랜잭션 이벤트를 공부해보려고한다.이벤트 — 일을 시키는 대신 "끝났다"고 알리기집을 사는 날을 떠올려 보면, 계약서에 도장을 찍는 자리에 이삿짐 센터 ..

개요목록 화면은 어디에나 있고, 페이징은 페이지 번호에 20을 곱해서 넘기면 끝이라고 생각했었다. 사실 관리자 화면 마지막 페이지가 왜 10초씩 걸리는지, 발송 배치가 왜 절반만 나가고 멀쩡히 끝나는지 한동안 원인을 못 찾았는데, 두 문제의 뿌리가 같은 한 단어 — 건너뛴 장도 읽는다 — 라는걸 알게되었다. 가끔씩 페이징 글을 보면 OFFSET 은 느리니 커서를 쓰라고 하고 끝~인 경우가 많아, 왜 느리고 왜 빠지는지는 늘 아쉬운 부분이었다. 그렇기에 이번글은 오프셋과 커서 페이징을 비교해보려고한다. 오프셋 페이징 — 건너뛰는 게 아니라 읽고 버린다두꺼운 책의 3,001번째 장을 보고 싶은데 이 책에는 쪽수가 인쇄되어 있지 않다고 해봅시다. 사서가 할 수 있는 일은 하나, 첫 장부터 한 장씩 넘기면서 세..

개요DB 가 잠깐 죽었다 살아났는데 서버는 30분 넘게 돌아오지 않은 적이 있다. 처음엔 쿼리 타임아웃을 걸어 뒀으니 당연히 몇 초 뒤 끊길 줄 알았지만, 스레드 덤프를 뜨니 전부 DB 응답을 기다리며 멈춰 있었다. 파다 보니 타임아웃이 한 개가 아니라 세 겹이고 — 그중 실제로 전화를 끊을 수 있는 시계는 하나뿐 — 이라는걸 알게되었다. 가끔씩 타임아웃 글을 보면 옵션 이름 나열하고 끝~인 경우가 많아, 어느 시계가 무엇을 재는지는 늘 아쉬운 부분이었다. 그렇기에 이번글은 소켓·쿼리·트랜잭션 세 시계를 전화 한 통으로 공부해보려고한다.소켓 타임아웃 — 침묵을 얼마나 참을 것인가고객센터에 전화를 걸었다. 상담원이 "잠시만요, 확인해 드릴게요" 하고는 말이 없다. 1분, 5분, 10분이 지나도 소리 하나 ..

개요회사에서 알림 서버를 새로 만들게 되면서 저장소를 NoSQL 로 할지 RDB 로 할지 골라야 했다. 처음엔 알림은 한 건씩 쌓이는 쪽지니까 당연히 NoSQL 아닌가? 싶었는데, 파보니 — 어떤 DB 냐보다 알림을 어떤 모양으로 담고 어떻게 버리느냐가 먼저 — 라는걸 알게되었다. 가끔씩 둘을 비교한 글을 보면 장단점 표 하나 놓고 끝~인 경우가 많아 늘 아쉬운 부분이었다. 그렇기에 이번글은 알림 서버라는 한 장면에서 두 방식이 어떻게 다른지 공부해보려고한다.담는 모양 — 복사해서 나눠 줄까, 한 장 붙이고 표시만 받을까아파트 관리사무소가 "금요일 엘리베이터 점검" 공지를 세 집에 알린다고 해 보겠습니다. 하나는 공지를 세 장 복사해 집집마다 우편함에 넣는 방법이고, 다른 하나는 게시판에 한 장만 붙이고..

개요배포할 때 테이블도 같이 바꾸는 일은 늘 있다. 처음엔 마이그레이션 파일에 ALTER 한 줄 넣고 배포 버튼 누르면 끝 아닌가? 싶었지만, 배포 중에는 옛 코드와 새 코드가 같은 테이블을 동시에 보는 시간이 반드시 생기고 그 몇 분이 장애의 대부분이라는걸 — 바꾸지 말고 옆에 추가하고, 기다리지 말고 포기해라 — 알게되었다. 가끔씩 Flyway 글을 보면 파일 이름 규칙 설명하고 끝~인 경우가 많아, 운영 중인 테이블을 어떻게 고치는지는 늘 아쉬운 부분이었다. 그렇기에 이번글은 무중단 스키마 변경을 공부해보려고한다.롤링 배포 — 옛 사서와 새 사서가 같은 대장을 본다도서관 대출대장 한 권을 사서 셋이 함께 쓴다고 해 봅시다. 대장 서식을 바꾸기로 했는데, 사서는 한 번에 한 명씩만 교대합니다. 그러니..

개요결제 버튼을 만들면서 재시도는 보내는 쪽이 알아서 하는 거라고 생각했었다. 처음엔 응답이 안 오면 그냥 한 번 더 보내면 되는거 아닌가? 싶었지만, 응답을 못 받았다는 건 실패했다는 뜻이 아니라 성공했는지 실패했는지 모른다는 뜻이고 그 상태에서 다시 보내면 결제가 두 번 나갈 수 있다는걸 알게되었다. 그러니까 — 다시 보내는 건 손님이지만, 한 번만 일어나게 하는 건 가게의 기억이다 — 라는게 이 글의 축이다. 가끔씩 멱등성 글을 보면 "요청에 키를 붙이고 저장하면 끝~"인 경우가 많아, 같은 키에 다른 내용이 오면 어떻게 되는지, 만드는 도중에 다시 오면 어떻게 되는지는 늘 아쉬운 부분이었다. 그렇기에 이번글은 멱등성 키를 분식집 전화 주문과 장부 이야기로 공부해보려고한다.재시도 — 응답이 없다는 ..

개요운영 서버를 컨테이너로 옮긴 다음 날, 주문 시각이 전부 9시간씩 밀려 있었다. 처음엔 DB 가 이상한가? 싶었지만 코드도 DB 도 그대로였고, 바뀐 건 서버가 보는 시계 하나였다는걸 알게되었다 — 시간은 하나인데 그걸 읽는 시계가 셋(프로그램·통역사·서랍) 이라는 얘기였다. 가끔씩 시간대 글을 보면 설정 한 줄 넣고 끝~인 경우가 많아, 왜 밀리는지는 늘 아쉬운 부분이었다. 그렇기에 이번글은 시각과 시계를 구분하는 것부터 시작해서, 시간 값이 프로그램에서 DB 까지 가는 길을 따라가보려고한다.시각과 벽시계 — 순간은 하나, 시계는 도시마다 다르다런던으로 출장 간 동료가 "내일 3시에 통화하자" 고 메시지를 보냈다. 서울의 3시인지 런던의 3시인지 묻지 않으면 둘 중 하나는 빈 전화기 앞에 앉아 있게..