그냥 바로 update쿼리 날리는게 낫지않음?
진짜로 검색해도 제대로 안나와서 물어보는거임
검색하면 select해와서 update하면 캐싱되서 성능최적화된다는데
그러면 단일서버 말고 다중서버의 경우에는? 한서버에서 select한다고 해서 그게 다른서버에도 자동으로 캐싱되지는 않지않음?
jpa에서 select해온걸 캐싱해놓고 쓴다는것도 이해가 좀 안됨
DB상에서 변경사항이 발생하면 그걸 어떻게 캐치하고 캐시지우고 다시 업데이트시키는거지?? SELECT 메서드 실행하면 DB에 확인절차를 거치나???
진짜로 검색해도 제대로 안나와서 물어보는거임
검색하면 select해와서 update하면 캐싱되서 성능최적화된다는데
그러면 단일서버 말고 다중서버의 경우에는? 한서버에서 select한다고 해서 그게 다른서버에도 자동으로 캐싱되지는 않지않음?
jpa에서 select해온걸 캐싱해놓고 쓴다는것도 이해가 좀 안됨
DB상에서 변경사항이 발생하면 그걸 어떻게 캐치하고 캐시지우고 다시 업데이트시키는거지?? SELECT 메서드 실행하면 DB에 확인절차를 거치나???
바로 update 날리는건 jdbc쓰는거지 jpa가 아닐건데
데이터 베이스 본질이 acid임. 그중 c가 consistency인데, 디비 입력 전후가 일관성이 있어야 된다는 말임.
댓글이 안써지네
왜 댓글이 씹히냐
길게 쓰면 씹히네
consistency는 님 은행계좌에서 친구한테 돈 송금하려고 30만원 뽑았다고 치자
만약 update 쿼리만 있으면 업데이트 어카운트 셋 ((셀렉트 밸런스 from 어카운트 where 아이디 = 내 아이디) - 30만원) 이렇게 됨
아 dc에서 sql injection 막으려고 댓글에 쿼리문 안되게 해놨구나
여튼 님 계좌에 10만원 있었는데, 30만원 송금하면, -20만원이 됨. 근데 이건 말이 안됨. 예금계좌에 마이너스 값이 있을 수가 없잖아? 그게 consistency가 깨졌다는 것
그래서 30만원 님 통장에서 빼기 전에 먼저 님 계좌에서 얼마 있는지 select해서 30만원 이상 있는지 확인해서 validation check for consistency 한 후에 update하는 것
오
그러면 두 사람이 동시에 업데이트하는 시나리오를 생각해보자 제목과 내용에 섹스라고 글써져잇는걸 두 사람이 동시에 수정버튼 누르고 한명이 제목을 먼저 자지라 바꾸고 업데이트한후 다른 사람이 내용을 보지라 바꿨다고 가정했을때 select후 업데이트를 하게되면 (merge가 아닌 더티체킹) 마지막 수정버튼 누를때 제목은 섹스 내용은 보지라 써잇어도 DB상에는
제목이 자지라 바뀐상태이기때문에 결과물은 제목:자지 내용:보지 이렇게 되는거임?
단어선정이 생각하는데 방해되잖아
update도 write이기 때문에, 디비에서 트랜젝션 검. 트랜젝션의 isolation이 제일 낮은 read_uncommitted조차 두 쓰레드가 동시에 하나의 row를 write할 수 없음
따라서 update에 트랜젝션 걸려있을 테니까, 두놈이 동시에 같은 row를 write하려고 하면, 한놈이 트랜젝션 건 상태에서 write하는 와중 다른놈은 트랜젝션 끝날 떄 까지 기다렸다가 write할 것. 따라서, 제목: 섹스 내용: 보지 가 되거나, 제목: 자지, 내용: 섹스 가 되겠지. 아 단어선정 개빡치네
같은 database row에 동시접근 했을 때, 락거는건 acid에 isolation에 해당하는데, isolation은 4가지 단계가 있음. read_uncommited, repeatable_read 등이 있고, 각 단계마다 dirty read, non-repeatable read, phantom read라는 허점이 있음
자세한건 chatgpt한테 물어보셈
select * from board - dc App