타유저 데이터에 Insert 하는방법

A유저와 B유저가 동시에 C유저의 데이터를 수정할 경우
A이나 B둘중 마지막으로 보낸 요청이 덮어 씌워지는 문제때문에

C유저의 데이터를 Insert하는 식으로 처리할려는데
정작 본인데이터를 Insert하는건 가능해도 타유저를 Insert할 수 없는 듯 한데

타유저 데이터 Insert 하는 방법 있을까요?

안녕하세요 개발자님,
타 유저의 데이터를 insert 하는 기능은 제공되지 않습니다.
퍼블릭 테이블에 한해 update로 타 유저의 데이터를 수정하는 기능만 제공됩니다.

그러면 데이터에 동시간에 접근했을 때 중복된 처리때문에 잘못된 값이 덮어씌워질 수 있는데
(ex
A유저와 B유저가 C유저의 데이터에 진입,
A유저 B유저 모두 5라는 재화값이 있는데
클라 처리에 따라 A는 +4해서 9, B는 +6해서 11로
이때 C의 데이터에 insert로 4와 6이라는 데이터를 저장하는게 현재 불가능,
따라서 9로 덮어씌워질지 11로 덮어씌워질지 예측할 수 없음)

이걸 근본적으로 해결할 수 있는 방법이 현재는 없는건가요?

단순히 숫자의 셈만을 하는 과정이시라면,
UpdateWithCalculationV2 함수를 통해 처리하시면 동시성 문제를 해결할 수 있습니다.

해당 함수는 기존 데이터를 불러와서 숫자를 계산하는 형태가 아니라 기존 데이터는 모르는 채로 연산만 해주는 역할이기 때문에 동시 진행이 가능한 점 참고하여 이용해 주시면 감사하겠습니다.

이것도 결국 동시성 문제가 발생할 수 밖에 없을 것 같은게

구현하려던 프로세스는
모든 유저가 접근 가능한 public 공용계정으로 생성한 데이터에
컨텐츠를 진행하여 클리어하면 본인의 UUID나 inDate 및 점령 시작시간을 넣어서 처리하고
이전에 점령했었던 유저는 점령했던 기간동안의 보상을 받는것입니다.
즉 뺏긴 그 순간, 단 한번의 보상을 받을 수 밖에 없는것인데

A과 B가 동시에 시작하여 동시간에 점령하면
UpdateWithCalculationV2도 2번 호출되어
사실상 보상을 두번 받을 수 있을 가능성이 생깁니다.

물론 실제로 이런 케이스가 발생할 확률은 드물다고는 하지만
이런 케이스가 1번이라도 발생되는 순간 추적도 어려워지고
이런 드문케이스를 추적하기 위해서 로그를 추가적으로 쓰던가 해야하는데
그런 부분에서도 또 비용이 발생합니다.

결국 이걸 해결할 수 있는 이론이 현재는 없다고 생각되는데 혹시 다른방법이 더 있을까요?

말씀하신 것처럼 점령전을 구현하고자 하시는 부분이라면,
동시성 문제로 인해 구현이 불가합니다.

좋아요 1

C유저 상태
ID 23번 198분
ID 32번 812분

들어가있는 데이터 값 = 23,198/32,812

C유저는 현재 35번 ID를 점령중이고 123분 진행함.
따라서
A유저 클리어시 서버에 전송 ->35,123/23,198/32,812
B유저 클리어시 서버에 전송 → 35,123/23,198/32,812

AB유저의 처리가 동시에 진행되었을 때 문제유발 X

이때 동시간에 C유저도 보상받기를 진행 시
23,198/32,812를 지워서 서버에 string.empty를 전송했는데

그 직후 바로 A가 데이터(35,123/23,198/32,812)를 서버에 전송하고
C유저가 보상을 업데이트 할 때 (35,123/23,198/32,812) 데이터를 수령받아
이미 받았던 보상 데이터를 중복 수령할 수 있는 가능성이 있으므로

C클라가 보상을 받았을 때 받았던 데이터(23,198/32,812)를 클라에 저장해놓고
데이터 업데이트 시 중복된 데이터 23,198/32,812는 클라에서 없는걸로 처리

예시엔 데이터에 ID와 분 정보밖에 없지만
23,198,2025-01-22T02:06:42.609Z/32,812,2025-01-23T02:05:43.609Z 이런식으로 날짜 정보도 추가 후

날짜를 기준으로 삼아서 처리

(A유저는 35,123,2025-01-23T02:05:43.107Z
B유저는 35,123,2025-01-23T02:05:43.231Z
이렇게 쐈는데
C유저는 2025-01-23T02:05:43.107Z를 수령받고 서버에 쏜 후
다시 2025-01-23T02:05:43.231Z 데이터를 수신받으면 중복처리 안되니까
날짜간격이 매우 미세하면 동일 데이터로 간주하기 위함)

이런식으로 진행하면 어떨 것 같으신가요?

이것도 이론상으로 100% 차단은 안될 것 같긴 한데

이정도면 고의적으로 재현하려고 해도 거의 불가능한 수준까지 될 것 같다고 생각돼요

남겨주신 설명상으로는 정확히 어떤 컨텐츠 구성인지 알지 못해 답변을 드리기 어려움이 있습니다.
단순히 동시성으로 인한 C의 보상 중복 수령을 걱정하시는 부분이라면,
말씀해주신 것과 같이 구성하시거나, 해당 정보를 바탕으로 특정 시간(예를들면 매 정시) 기준으로만 수령을 할 수 있는 등의 조건을 추가하시는 것도 방법이 될 수 있을것 같습니다.

좋아요 1