회원관리프로그램 생각보다 쉽지 않네요
글쓴이: lalupo20 / 작성시간: 수, 2021/08/18 - 4:17오후
정보란이 A, B, C, D가 있을때
두사람이 거의 동시에 동일한 회원정보에 접근
첫번째 사람이 A정보만 수정하고 저장
두번째 사람이 B정보만 수정하고 저장
하면
두번째 사람에게는 A가 수정한 정보들이 업데이트 안되어 있기때문에
첫번째 사람이 수정한 A 정보가 날라감
이런 문제가 있었네요.
이런거 서버를 두어야만 대비할 수 있는 부분일까요?
정보가 수정되면 실시간으로 업데이트 되어야 할거 같은데...
아니면 누가 접근중인 회원이면 다른 사람이 접근할 수 없게 하거나
Forums:
https://en.wikipedia.org/wiki
https://en.wikipedia.org/wiki/Record_locking 참고하셔요.
세벌 https://sebuls.blogspot.kr/
그래서 history 테이블로 관리하는 경우도 있습니다.
그래서 history 테이블로 관리하는 경우가 있습니다.
다만 이 경우 개발및 유지 보수 비용이 비싸기때문에 신중하게 접근할 필요가 있습니다.
==============
여기서 부터는 본문 내용과 상관없는 잡설입니다.
hisotry 테이블 방법이라든지
lock 을 걸고 풀어주는 방식이라든지
DB lock 이 기본 베이스인건 맞지만 DB lock 이 전부가 아닙니다.
어떤 문제가 있는데 이를 해결하기 위해서 어떤 전략을 갖고 DB 를 관리하여 운영할것인가?
이게 핵심입니다.
회원 정보 파일이 단일 파일인가 보네요.
회원 정보 파일이 단일 파일인가 보네요.
수정된 정보만 file seek로 정확한 회원 정보 위치만 찾아서 그 부분만 업데이트 하시면 되지 않나요?
물론 파일 접근 시에는 상호 배제(mutual exclusion)가 보장되어야 합니다.
스쳐가는 생각
하나의 방법으로...
정보 수정을 위한 폼을 만들때,
마지막 갱신시각을 숨김필드로 값을 갖고 있다가
(갱신시각 또는 사용자 정보를 기반으로 생성된 해시값 등)
서버가 폼값을 받아 데이터베이스를 업데이트할때 갱신일자를 비교해서
일치한다면 정상적으로 데이터베이스를 업데이트 하고,
불일치하면 데이터베이스 업데이트 작업을 하지 않으면서
수정을 요청한 사용자에게 에러나 경고 메시지를 주는 방법이 떠오르네요.
(이 시나리오에서 데이터베이스는 업데이트 동작을 순차적으로 실행해야 합니다.)
갱신시각 정보 만으로는 부족하고, 갱신 회수 또는 랜덤넘버 등,
가능하다면 (적당히) 더 많은 추가 정보가 있을 수록 좋을 것 같습니다.
또다른 방법은...
폼에 있는 레코드 전체를 받아들여 데이터베이스에 그대로 덮어쓰는 방식이 아닌,
사용자가 명시적으로 변경한 각 필드에 대해 변경 플래그를 설정하고
서버는 변경 요청 플래그가 설정된 필드만 업데이트 하는 겁니다.
변경 플래그는 단순히 '사용자 입력 유무' 만으로 판단 할수도 있겠지만,
좀더 정교하게 하자면, '수정전 필드 데이터'와 '요청 필드 데이터'를 직접 비교하여 일치/불일치를 확인할수도 있겠습니다.
그리고 위 두방법의 장점을 혼합한 방식도 가능하겠습니다.
스쳐지나가는 생각이었지만
'이 정도'는 적절한 이름이 붙여져 이미 구현된 방법일거라 생각되네요.