Transaction Action on Game Server Services | Docs

Game Engine

Mon, 01 Jan 0001 00:00:00 +0000

트랜잭션이란

GS2에서의 트랜잭션 처리란, “소비 액션"과 “입수 액션"으로 정의된 리소스 교환 처리를 실행하는 덩어리를 가리킵니다. 트랜잭션을 발행하는 API에는 GS2-Exchange의 교환 실행 함수(Exchange), GS2-Showcase의 상품 구매 함수(Buy), GS2-Quest의 퀘스트 시작 함수(Start)와 같은 것들이 있습니다.

“소비 액션"은 플레이어에게 불리하게 작용하는 사용자 데이터 조작을, 반대로 “입수 액션"은 플레이어에게 이득이 되는 사용자 데이터 조작을 가리킵니다.

구체적으로 GS2-Inventory라면 아이템의 소비가 “소비 액션”, 아이템의 입수가 “입수 액션"이 됩니다. 조금 색다른 예를 들면, GS2-Inbox의 메시지 개봉 플래그를 세우는 조작이 “소비 액션”, 메시지에 첨부된 아이템을 수령하는 것이 “입수 액션"이 됩니다. GS2에서는 사용자 데이터를 다시 쓰는 트랜잭션을 발행하고 실행하는 것을 반복함으로써 게임 사이클을 실현한다고 이해하십시오.

SDK

Mon, 01 Jan 0001 00:00:00 +0000

GS2-SDK for Game Engine의 트랜잭션 처리에 대해

기본적인 개념과 처리 흐름은 for Game Engine 문서를 참조하십시오. 한편, GS2-SDK에서는 for Game Engine만큼 충실한 지원은 제공되지 않습니다.

구체적으로는 캐시 기능이나 EzTransactionDomain과 같은 구조는 마련되어 있지 않습니다.

트랜잭션 실행

자동 실행이 유효한 경우

완료 통지를 받으려면 명시적으로 GS2-Gateway에 사용자ID를 설정해야 합니다.

GS2-Gateway::setUserId

완료 통지를 핸들링해야 합니다. Gs2WebSocketSession 클래스에 통지를 핸들링하는 함수가 마련되어 있으므로 이를 이용하십시오. 프로그래밍 언어에 따라서는 WebSocket 클라이언트 구현이 없을 수도 있습니다.

스탬프 시트

Mon, 01 Jan 0001 00:00:00 +0000

GS2에서는 각 서비스 간을 연계시키는 트랜잭션 구조로서 《스탬프 시트》라는 구조를 사용합니다.

GS2 내의 API 중, 플레이어에게 불이익이 되는 조작을 《소비 액션》이라고 부르고, 반대로 플레이어에게 이익이 되는 조작을 《입수 액션》이라고 부릅니다.

게임 내 상점에서 《1000 젬을 사용》하여 《가챠를 10번 뽑는》처리가 있다고 합시다. 이 경우, 《1000 젬을 사용》이 소비 액션이고, 《가챠를 10번 뽑는》것을 입수 액션으로 볼 수 있습니다.

조금 더 예시를 나열해 보겠습니다.

《메시지를 읽음 처리》하는 소비 액션을 실행하고 《메시지에 첨부된 젬 100개를 수령》하는 입수 액션을 실행한다
《스태미나를 10 소비》하는 소비 액션을 실행하고 《퀘스트 1을 시작 상태로 만드는》 입수 액션을 실행한다
《퀘스트 1의 시작 상태를 삭제》하는 소비 액션을 실행하고 《퀘스트 1의 클리어 보상을 입수》하는 입수 액션을 실행한다
《현재 시각으로 최종 방치 보상 수령 시간을 갱신》하는 소비 액션을 실행하고 《방치 시간에 따른 보상을 입수》하는 입수 액션을 실행한다
《매일 초기화되는 횟수 제한 카운터를 1 증가》하는 소비 액션을 실행하고 《하루 1회만 받을 수 있는 아이템을 입수》하는 입수 액션을 실행한다

이처럼 GS2에서는 모든 게임 사이클이 무언가를 소비하고, 무언가를 얻는 것으로 표현됩니다.

트랜잭션 설정

Mon, 01 Jan 0001 00:00:00 +0000

GS2가 제공하는 마이크로서비스에는 대체로 네임스페이스 설정에 transactionSettingV2라는 필드가 존재합니다. 해당 네임스페이스가 발행하는 트랜잭션을 어떻게 실행할지는 이 설정으로 정해집니다.

TransactionSettingV2는 다음과 같은 구조를 가집니다.

	타입	활성화 조건	필수	기본값	값 제한	설명
distributorNamespaceId	string		✓	“grn:gs2:{region}:{ownerId}:distributor:default”	~ 1024자	트랜잭션 실행에 사용하는 GS2-Distributor 네임스페이스
enableParallelExecution	bool		✓	false		액션을 직렬이 아닌 병렬로 실행할지 여부

설정하는 항목은 이 2가지뿐입니다. 트랜잭션의 실행 방법에 관한 그 밖의 항목은 권장 구성으로 고정되어 있으므로, 어느 쪽을 선택하더라도 다음 3가지는 항상 성립합니다.

트랜잭션 액션의 조합

Mon, 01 Jan 0001 00:00:00 +0000

각 서비스의 API 레퍼런스에는 「하나의 트랜잭션에 지정할 수 있는 조합」이라는 표가 있습니다. 이 페이지는 그 표를 읽기 위한 전제를 정리한 것입니다.

액션의 「종별」

각 서비스의 액션 표에 있는 「종별」은 그 액션을 트랜잭션의 검증·소비·획득 중 어느 목록에 둘 수 있는지를 나타냅니다.

액션의 이름이나 실제 효과와 일치하지 않는 경우가 있습니다. 이름이 Verify라도 소비 액션이거나, 아무것도 업데이트하지 않는데 획득 액션인 경우가 있습니다.

각 서비스의 표를 읽는 법

각 서비스의 페이지에는 그 서비스의 조작을 나열한 표가 있습니다.

GS2-AdReward 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-AdReward 고유의 내용입니다.

GS2-AdReward의 트랜잭션 액션은 네임스페이스와 사용자별로 하나만 존재하는 포인트 잔액을 대상으로 합니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
포인트의 획득 `AcquirePointByUserId`	통합되어 포인트가 합산된다	합산된다	네임스페이스·사용자	변하지 않는다. 원래부터 합산되어 성립한다
포인트의 소비 `ConsumePointByUserId`	통합되어 합계액으로 잔액이 판정된다	합산된다. 다만 합계가 잔액을 초과한 경우에는 충돌(409)이 되며, 잔액이 늘지 않는 한 재시도해도 해소되지 않는다	네임스페이스·사용자	변하지 않는다. 충돌이 되는 경우를 포함해 동작은 동일하다

두 행 모두 같은 잔액에 대한 순수한 증분으로 기록되므로, 획득과 소비를 함께 두어도 각각이 적용됩니다. 획득 100과 획득 50을 지정하면 포인트 150의 획득 1건으로 취급됩니다. 잔액 100에 대해 소비 60과 소비 30을 지정하면 잔액은 10이 되고, 소비 60과 획득 200을 지정하면 잔액은 240이 됩니다.

GS2-Dictionary 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Dictionary 고유의 내용입니다.

GS2-Dictionary의 트랜잭션 액션은 네임스페이스와 사용자의 조합으로 결정되는 한 사용자의 도감, 즉 획득한 엔트리 목록을 대상으로 합니다. 엔트리의 추가·삭제는 이 목록을 통째로 다시 쓰는 형태로 반영됩니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
엔트리의 추가 `AddEntriesByUserId`	통합되어 엔트리 이름이 중복을 제외하고 결합된다	실패한다	네임스페이스·사용자	성립한다. 안쪽에서 도착하는 추가는 바깥쪽이 이미 기록한 상태 위에 적용된다
엔트리의 삭제 `DeleteEntriesByUserId`	통합되어 엔트리 이름이 중복을 제외하고 결합된다	실패한다	네임스페이스·사용자	성립한다. 안쪽에서 도착하는 삭제는 바깥쪽이 이미 기록한 상태 위에 적용된다
엔트리의 검증 `VerifyEntryByUserId`	완전히 같은 검증은 1건으로 묶인다	읽기만 하므로 충돌하지 않는다	엔트리·검증 타입	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다

추가와 삭제는 행이 다르고 경계가 같습니다. 하나의 도감에 대한 추가와 삭제를 같은 트랜잭션에서 수행할 수는 없습니다. 트랜잭션을 나누어 주십시오. 직렬 실행 모드(enableSequentialExecution 또는 TransactionSettingV2)를 활성화하면 이 제약이 사라집니다. 액션이 한 건씩 실행되고, 나중에 실행되는 쪽은 먼저 실행된 액션이 기록한 상태를 읽은 뒤 실행되므로, 같은 도감에 대한 추가와 삭제를 하나의 트랜잭션에 넣을 수 있게 됩니다.

GS2-Distributor 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Distributor 고유의 내용입니다.

GS2-Distributor의 트랜잭션 액션은 데이터가 아니라 로직을 다룹니다. 다른 액션을 안쪽에 가지고, 그것들을 실행할지 여부를 결정합니다. GS2-Distributor는 자신의 데이터를 갖지 않으므로, 이러한 액션이 GS2-Distributor를 이유로 충돌하는 일은 없습니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
`and` 식의 평가 `AndExpressionByUserId`	각각 독립적으로 평가된다	읽기만 하므로 충돌하지 않는다	식마다 다른 대상	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다
`or` 식의 평가 `OrExpressionByUserId`	각각 독립적으로 평가된다	읽기만 하므로 충돌하지 않는다	식마다 다른 대상	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다
`if` 식의 평가 `IfExpressionByUserId`	각각 독립적으로 평가된다	성립한 분기가 무엇을 기록하는지에 따른다	식마다 다른 대상	계속해서 성립한 분기가 무엇을 기록하는지에 따르지만, 그 기록은 같은 직렬 실행 구간을 거치게 된다(아래 설명 참고)

and와 or 식이 안쪽에 가지는 것은 검증 액션으로, 읽기만 수행합니다. if 식은 두 개의 분기에 소비 액션을 가지며, 이쪽은 기록합니다.

GS2-Enchant 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Enchant 고유의 내용입니다.

GS2-Enchant의 트랜잭션 액션은 2종류의 스테이터스를 다룹니다. 둘 다 네임스페이스·사용자·파라미터 모델·프로퍼티의 조합으로 결정되며, 업데이트할 때마다 전체가 다시 쓰입니다.

밸런스 파라미터의 스테이터스
레어리티 파라미터의 스테이터스

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
밸런스 파라미터의 다시 뽑기 `ReDrawBalanceParameterStatusByUserId`	완전히 동일한 지정이라도 발행 시에 오류	실패한다	네임스페이스·사용자·파라미터 모델·프로퍼티 (밸런스)	중첩을 넘어서도 성립한다. 나중에 실행된 쪽의 다시 뽑기 결과가 된다
밸런스 파라미터의 설정 `SetBalanceParameterStatusByUserId`	같은 값이면 통합. 값이 다르면 발행 시에 오류	실패한다	네임스페이스·사용자·파라미터 모델·프로퍼티 (밸런스)	중첩을 넘어서도 성립한다. 같은 값이면 통과하고, 값이 다르면 나중에 실행된 쪽의 값이 된다
레어리티 파라미터의 다시 뽑기 `ReDrawRarityParameterStatusByUserId`	완전히 동일한 지정이라도 발행 시에 오류	실패한다	네임스페이스·사용자·파라미터 모델·프로퍼티 (레어리티)	중첩을 넘어서도 성립한다. 나중에 실행된 쪽의 다시 뽑기 결과가 된다
레어리티 파라미터의 가산 `AddRarityParameterStatusByUserId`	통합되어 수가 합산된다	실패한다	네임스페이스·사용자·파라미터 모델·프로퍼티 (레어리티)	성립한다. 중첩을 넘어서도 합산된다
레어리티 파라미터의 설정 `SetRarityParameterStatusByUserId`	같은 값이면 통합. 값이 다르면 발행 시에 오류	실패한다	네임스페이스·사용자·파라미터 모델·프로퍼티 (레어리티)	중첩을 넘어서도 성립한다. 같은 값이면 통과하고, 값이 다르면 나중에 실행된 쪽의 값이 된다
검증 `VerifyRarityParameterStatusByUserId`	완전히 같은 검증은 1건으로 묶인다	읽기만 하므로 충돌하지 않는다	스테이터스·검증 타입·파라미터 이름·수	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다

합산할 수 있는 값을 갖는 것은 레어리티 파라미터의 가산뿐입니다. 다시 뽑기와 설정은 스테이터스 전체를 교체하므로, 같은 스테이터스를 건드리는 다른 행과 함께 둘 수 없습니다. 직렬 실행 모드(enableSequentialExecution 또는 TransactionSettingV2)를 활성화하면 액션이 한 건씩 실행되고 각 액션이 직전 액션의 쓰기를 볼 수 있게 되므로 이 제약이 사라집니다. 같은 스테이터스에 대해 이 행들을 어떻게 조합하든 하나의 트랜잭션에 넣을 수 있게 됩니다. 페이즈 안에서의 실행 순서는 액션 이름으로 결정되므로, 레어리티 파라미터의 가산은 반드시 다시 뽑기보다 먼저, 설정은 반드시 뒤에 실행됩니다. 따라서 가산은 뒤따르는 다시 뽑기에 의해 버려지고, 설정은 그때까지의 결과를 덮어씁니다. 같은 스테이터스에 대한 다시 뽑기 두 개를 나란히 지정한 경우에는 완전히 동일한 액션이 중복되어 어느 쪽 결과를 채택해야 할지 구별할 수 없으므로, 발행 시 오류인 채로 남습니다.

GS2-Enhance 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Enhance 고유의 내용입니다.

GS2-Enhance의 트랜잭션 액션은 진행을 거치는 것과 거치지 않는 것 두 가지로 나뉩니다. 진행은 네임스페이스와 사용자의 조합으로 결정되며, 사용자당 하나만 존재합니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
진행의 생성 `CreateProgressByUserId`	1건으로 통합된다	실패한다	네임스페이스·사용자	생성끼리의 충돌은 변하지 않고 계속 실패한다. 두 번째는 실제 중복을 막는 것과 같은 읽기로 첫 번째의 진행을 볼 수 있게 되어 “이미 존재한다"고 거부되기 때문이다. 두 번째에 `force`를 지정해도 해결되지 않는다. 이 경우 확인은 건너뛰지만, 같은 행에 대한 두 개의 쓰기를 하나로 묶을 수 없어 트랜잭션이 실패한다(400). 파기와의 충돌도 계속 실패한다(후술)
진행의 파기 `DeleteProgressByUserId`	1건으로 통합된다	실패한다	네임스페이스·사용자	계속 실패한다. 1건으로 묶이지 않게 되므로, 두 번째 파기는 이미 사라진 진행에 대해 실행되어 찾을 수 없음(404)으로 거부된다
직접 강화·해방 `DirectEnhanceByUserId` `UnleashByUserId`	강화 레이트·대상·소재가 모두 같으면 1건으로 통합된다. 하나라도 다르면 각각 실행된다	진행을 건드리지 않는다	네임스페이스·사용자·강화 레이트·대상 아이템·소재	변하지 않는다. 진행을 건드리지 않는 것은 그대로다

생성과 파기는 행이 다르고 경계가 같습니다. 하나의 트랜잭션에 넣을 수는 없습니다.

GS2-Exchange 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Exchange 고유의 내용입니다.

GS2-Exchange의 트랜잭션 액션은 교환 대기를 거치는 것과 한 번에 교환하는 것 두 가지로 나뉩니다. 교환 대기는 네임스페이스·사용자·교환 대기 이름의 조합으로 결정됩니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
교환 대기의 생성 `CreateAwaitByUserId`	같은 교환 레이트라면 통합되어 수가 합산된다	실패한다	네임스페이스·사용자·교환 레이트	성립한다. 다만 통합되지는 않는다. 교환 대기의 이름은 서버가 매기므로, 중첩에서 도착한 생성은 1건째의 수에 더해지는 것이 아니라 2건째의 교환 대기로 늘어난다
교환 대기의 스킵 `SkipByUserId`	`skipType`이 같으면 통합된다. 다르면 발행 시에 오류	실패한다	네임스페이스·사용자·교환 대기	중첩을 넘어서도 성립한다. 2건째의 스킵은 1건째가 남긴 상태의 교환 대기에 적용된다. 나란히 작성한 `skipType` 불일치를 거부하는 동작은 발행 시에 작동하므로 변하지 않는다
교환 대기 결과의 수령 `AcquireForceByUserId`	1건으로 통합된다	실패한다	네임스페이스·사용자·교환 대기	계속 실패한다. 1건으로 묶이지 않게 되므로, 2건째는 1건째가 이미 지운 교환 대기에 대해 실행되어 찾을 수 없음(404)으로 거부된다
교환 대기의 파기 `DeleteAwaitByUserId`	1건으로 통합된다	실패한다	네임스페이스·사용자·교환 대기	결과 수령과 같은 이유로 계속 실패한다. 2건째의 파기는 이미 사라진 교환 대기에 대해 실행되어 찾을 수 없음(404)으로 거부된다
한 번에 교환 `ExchangeByUserId` `IncrementalExchangeByUserId`	같은 레이트라면 통합되어 수가 합산된다	교환 대기를 건드리지 않는다	네임스페이스·사용자·교환 레이트	변하지 않는다. 교환 대기를 건드리지 않는다

스킵의 합성 방법은 skipType에 따라 달라집니다. 분 지정끼리는 합산되고, 총 시간에 대한 비율끼리는 가산되며, 남은 시간에 대한 비율끼리는 순서대로 적용한 것과 같은 결과가 되도록 합성됩니다. 완료 지정끼리는 1건으로 묶입니다.

GS2-Experience 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Experience 고유의 내용입니다.

GS2-Experience의 트랜잭션 액션은 네임스페이스·사용자·경험치 모델·프로퍼티의 조합으로 결정되는 하나의 스테이터스를 대상으로 합니다. 스테이터스는 경험치·랭크·랭크 상한·다음 랭크업에 필요한 경험치를 함께 보관합니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
경험치의 가산 `AddExperienceByUserId`	통합되어 값이 합산된다	실패한다	네임스페이스·사용자·경험치 모델·프로퍼티	변하지 않고 계속 실패한다. 가산은 경험치에 대한 증분으로 기록되며, 같은 스테이터스에 대한 두 개의 증분은 각자가 가진 검사를 하나로 묶을 수 없기 때문이다
경험치의 감산 `SubExperienceByUserId`	통합되어 값이 합산된다	실패한다	네임스페이스·사용자·경험치 모델·프로퍼티	경험치의 가산과 같은 이유로 변하지 않고 계속 실패한다
경험치의 설정 `SetExperienceByUserId`	같은 값이면 통합. 값이 다르면 발행 시에 오류	실패한다	네임스페이스·사용자·경험치 모델·프로퍼티	중첩을 넘어서도 성립한다. 같은 값이면 통과하고, 값이 다르면 나중에 실행된 쪽의 값이 된다
랭크 상한의 가산 `AddRankCapByUserId`	통합되어 값이 합산된다	실패한다	네임스페이스·사용자·경험치 모델·프로퍼티	성립한다. 중첩을 넘어서도 합산된다
랭크 상한의 감산 `SubRankCapByUserId`	통합되어 값이 합산된다	실패한다	네임스페이스·사용자·경험치 모델·프로퍼티	성립한다. 중첩을 넘어서도 합산된다
랭크 상한의 설정 `SetRankCapByUserId`	같은 값이면 통합. 값이 다르면 발행 시에 오류	실패한다	네임스페이스·사용자·경험치 모델·프로퍼티	중첩을 넘어서도 성립한다. 같은 값이면 통과하고, 값이 다르면 나중에 실행된 쪽의 값이 된다
다른 액션으로의 전개 `MultiplyAcquireActionsByUserId`	통합되어 안쪽 액션이 하나의 리스트로 묶인다	자신은 아무것도 업데이트하지 않는다	—	변하지 않는다. 자신은 아무것도 업데이트하지 않는다
검증 액션 전반	완전히 같은 검증은 1건으로 묶인다	읽기만 하므로 충돌하지 않는다	스테이터스·검증 타입·필요 랭크 / 랭크 상한	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다

업데이트하는 6개의 행은 모두 경계가 같습니다. 같은 스테이터스에 대해 다른 행을 두 개 넣으면 트랜잭션이 실패합니다. 경험치의 가산과 랭크 상한의 가산, 가산과 감산, 가산과 설정은 모두 하나의 경계에 대한 두 개의 행입니다. 값을 합산할 수 있는 것은 같은 행의 액션끼리뿐입니다. 직렬 실행 모드(enableSequentialExecution 또는 TransactionSettingV2)를 활성화하면 이 제약의 일부는 사라지지만, 경험치 자체에 대해서는 남습니다. 경험치의 설정과 랭크 상한 3개 행은 스테이터스 전체를 다시 쓰므로, 같은 스테이터스에 대해 이 중 두 개를 하나의 트랜잭션에 넣을 수 있게 됩니다. 값은 정규화된 실행 순서로 나중에 실행된 액션의 값이 됩니다(작성한 순서가 아닙니다). 경험치의 가산·감산은 다릅니다. 이들은 경험치에 대한 증분으로 기록되며, 다른 증분과도, 뒤에 실행되는 스테이터스 전체의 재작성과도 묶을 수 없습니다. 경험치의 가산·감산은 하나의 트랜잭션에서 하나의 스테이터스에 한 건까지만 두고, 같은 스테이터스에 대한 랭크 상한 갱신이나 설정을 함께 두지 마십시오.

GS2-Formation 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Formation 고유의 내용입니다.

GS2-Formation의 트랜잭션 액션은 2종류의 대상을 다룹니다.

몰드 : 네임스페이스·사용자·몰드 모델의 조합으로 결정됩니다. 폼을 몇 개 가질 수 있는지라는 용량을 보관합니다.
폼 : 네임스페이스·사용자·몰드 모델·인덱스의 조합으로 결정됩니다. 하나의 슬롯에 설정된 프로퍼티를 보관합니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
용량의 가산·감산 `AddMoldCapacityByUserId` `SubMoldCapacityByUserId`	혼재해도 된다. 통합되어 값이 합산된다	합산된다	네임스페이스·사용자·몰드 모델	변하지 않는다. 원래부터 합산되어 성립한다
용량의 설정 `SetMoldCapacityByUserId`	같은 값이면 통합. 값이 다르면 발행 시에 오류	같은 값이면 그 값이 설정된다. 값이 다르면 실행 시에 실패한다	네임스페이스·사용자·몰드 모델	값이 달라도 성립한다. 나중에 실행된 쪽의 값이 된다
폼의 설정 `SetFormByUserId`	같은 값이면 통합. 값이 다르면 발행 시에 오류	같은 값이면 그 값이 설정된다. 값이 다르면 실행 시에 실패한다	네임스페이스·사용자·몰드 모델·인덱스	값이 달라도 성립한다. 나중에 실행된 쪽의 값이 된다
다른 액션으로의 전개 `AcquireActionsToFormProperties` `AcquireActionsToPropertyFormProperties`	전달하는 획득 액션이 같으면 통합된다. 다르면 각각 실행된다	폼 자체는 건드리지 않는다	네임스페이스·사용자·몰드 모델·인덱스·전달하는 획득 액션	변하지 않는다. 폼 자체는 건드리지 않는다

용량은 1 이상이어야 하고 몰드 모델의 최대 용량을 넘을 수 없습니다. 통합 후의 합계에 대해 판정되므로, 단독으로는 들어가는 가산이라도 다른 가산과 합쳐지면 거부될 수 있습니다.

GS2-Friend 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Friend 고유의 내용입니다.

GS2-Friend가 트랜잭션에 지정할 수 있는 액션은 1가지입니다. 프로필은 네임스페이스와 사용자의 조합으로 결정되며, 사용자당 하나입니다. 업데이트할 때마다 전체가 다시 쓰입니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
프로필의 업데이트 `UpdateProfileByUserId`	같은 값이면 하나로 합쳐짐. 값이 다르면 오류 (400)	같은 값이면 통과. 값이 다르면 실패한다	네임스페이스·사용자	변하지 않는다. 같은 값이면 통과하고, 값이 다르면 계속 오류(400)다. 프로필의 세 항목은 값의 절대 지정으로 기록되므로, 나중에 실행된 쪽이 앞의 값을 조용히 덮어쓰는 것은 허용되지 않는다. 지정하지 않은 항목은 비어 있는 값으로 기록되므로, 각각 다른 항목만 갱신하는 두 건도 “값이 다르다"로 취급된다

업데이트는 프로필 전체를 교체하므로, 두 개의 업데이트를 합성할 수 없습니다. 내용이 완전히 같은 업데이트는 하나로 합쳐지고, 값이 다른 업데이트는 트랜잭션 발행 시에 오류가 됩니다. 이는 다른 서비스의 절대값 액션(Set으로 시작하는 것)과 같은 취급입니다. 설정하고자 하는 프로필을 하나로 정하여 한 번만 지정해 주십시오.

GS2-Grade 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Grade 고유의 내용입니다.

GS2-Grade의 트랜잭션 액션은 ApplyRankCapByUserId를 제외하고, 네임스페이스·사용자·그레이드 모델·프로퍼티의 조합으로 결정되는 하나의 그레이드 스테이터스를 대상으로 합니다. 스테이터스는 업데이트할 때마다 전체가 다시 쓰입니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
그레이드의 가산 `AddGradeByUserId`	통합되어 값이 합산된다	실패한다	네임스페이스·사용자·그레이드 모델·프로퍼티	성립한다. 중첩을 넘어서도 합산된다
그레이드의 감산 `SubGradeByUserId`	통합되어 값이 합산된다	실패한다	네임스페이스·사용자·그레이드 모델·프로퍼티	성립한다. 중첩을 넘어서도 합산된다
랭크 상한의 적용 `ApplyRankCapByUserId`	1건으로 통합된다	GS2-Experience 쪽의 취급을 따른다	기록 대상인 GS2-Experience의 스테이터스	변하지 않는다. 결과는 그대로 GS2-Experience 쪽의 취급을 따른다
다른 액션으로의 전개 `MultiplyAcquireActionsByUserId`	통합되어 안쪽 액션이 하나의 리스트로 묶인다	자신은 아무것도 업데이트하지 않는다	—	변하지 않는다. 자신은 아무것도 업데이트하지 않는다
검증 액션 전반	완전히 같은 검증은 1건으로 묶인다	읽기만 하므로 충돌하지 않는다	그레이드 스테이터스·검증 타입·필요 그레이드	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다

가산과 감산은 행이 다르고 경계가 같습니다. 같은 스테이터스에 대한 가산과 감산을 하나의 트랜잭션에 넣을 수는 없습니다. 직렬 실행 모드(enableSequentialExecution 또는 TransactionSettingV2)를 활성화하면 액션이 한 건씩 실행되고 각 액션이 직전 액션의 쓰기를 볼 수 있게 되므로 이 제약이 사라집니다. 같은 스테이터스에 대한 가산과 감산을 하나의 트랜잭션에 넣을 수 있게 되며, 실제로 실행된 순서로 합산됩니다.

GS2-Guild 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Guild 고유의 내용입니다.

GS2-Guild의 트랜잭션 액션은 네임스페이스·길드 모델·길드 이름의 조합으로 결정되는 하나의 길드를 대상으로 합니다. 대상이 사용자가 아니라 길드라는 점에 주의해 주십시오. 어떤 사용자에 대해 발행한 트랜잭션이 다수의 사용자가 공유하는 것을 업데이트하게 됩니다. 길드는 업데이트할 때마다 전체가 다시 쓰입니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
최대 멤버 수의 가산 `IncreaseMaximumCurrentMaximumMemberCountByGuildName`	통합되어 값이 합산된다	실패한다	네임스페이스·길드 모델·길드 이름	성립한다. 중첩을 넘어서도 합산된다
최대 멤버 수의 감산 `DecreaseMaximumCurrentMaximumMemberCountByGuildName`	통합되어 값이 합산된다	실패한다	네임스페이스·길드 모델·길드 이름	성립한다. 중첩을 넘어서도 합산된다
최대 멤버 수의 설정 `SetMaximumCurrentMaximumMemberCountByGuildName`	같은 값이면 통합. 값이 다르면 발행 시에 오류	실패한다	네임스페이스·길드 모델·길드 이름	중첩을 넘어서도 성립한다. 같은 값이면 통과하고, 값이 다르면 나중에 실행된 쪽의 값이 된다
최대 멤버 수의 검증 `VerifyCurrentMaximumMemberCountByGuildName`	완전히 같은 검증은 1건으로 묶인다	읽기만 하므로 충돌하지 않는다	길드·검증 타입·인원 수	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다
멤버임의 검증 `VerifyIncludeMemberByUserId`	완전히 같은 검증은 1건으로 묶인다	읽기만 하므로 충돌하지 않는다	길드·검증 타입·대상 사용자	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다

업데이트하는 3개의 행은 경계가 같습니다. 하나의 길드에 대해 가산·감산·설정을 섞을 수는 없습니다. 직렬 실행 모드(enableSequentialExecution 또는 TransactionSettingV2)를 활성화하면 액션이 한 건씩 실행되고 각 액션이 직전 액션의 쓰기를 볼 수 있게 되므로 이 제약이 사라집니다. 하나의 길드에 대해 가산·감산·설정을 하나의 트랜잭션에 섞을 수 있게 되며, 가산과 감산은 실제로 실행된 순서로 합산되고, 설정이 섞여 있는 경우에는 나중에 실행된 쪽의 값이 됩니다.

GS2-Idle 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Idle 고유의 내용입니다.

GS2-Idle의 트랜잭션 액션은 네임스페이스·사용자·카테고리의 조합으로 결정되는 하나의 스테이터스를 대상으로 합니다. 스테이터스는 최대 방치 시간과 방치의 진행 상황을 보관하며, 각 액션은 자신이 변경하는 값만 기록합니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
최대 방치 시간의 가산·감산 `IncreaseMaximumIdleMinutesByUserId` `DecreaseMaximumIdleMinutesByUserId`	혼재해도 된다. 통합되어 값이 합산된다	합산된다	네임스페이스·사용자·카테고리·최대 방치 시간	변하지 않는다. 원래부터 합산되어 성립한다
최대 방치 시간의 설정 `SetMaximumIdleMinutesByUserId`	같은 값이면 통합. 값이 다르면 발행 시에 오류	실패한다	네임스페이스·사용자·카테고리·최대 방치 시간	같은 값이면 중첩을 넘어서도 성립한다. 값이 다른 경우는 계속 오류(400)다. 값의 절대 지정이므로 나중에 실행된 쪽이 앞의 값을 조용히 덮어쓰는 것은 허용되지 않는다
보상의 수령 `ReceiveByUserId`	실패한다	실패한다	네임스페이스·사용자·카테고리·방치의 진행 상황	계속 실패한다. 다만 이유가 달라진다(아래 참조)

최대 방치 시간은 통합 후의 합계에 대해 판정되며 카테고리에서 허용된 범위에 들어가야 하므로, 단독으로는 들어가는 가산이라도 다른 가산과 합쳐지면 거부될 수 있습니다.

GS2-Inbox 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Inbox 고유의 내용입니다.

GS2-Inbox의 트랜잭션 액션은 네임스페이스·사용자·메시지의 조합으로 결정되는 한 통의 메시지를 대상으로 합니다. 발송은 항상 새로운 메시지를 만들므로, 발송할 때마다 다른 대상이 됩니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
메시지의 발송 `SendMessageByUserId`	각각이 다른 메시지가 된다. 충돌하지 않는다	충돌하지 않는다	발송할 때마다 다른 대상	변하지 않는다. 원래부터 충돌하지 않는다
메시지의 개봉 `OpenMessageByUserId`	1건으로 통합된다	실패한다	네임스페이스·사용자·메시지	계속 실패한다. 1건으로 묶이지 않게 되므로, 2건째는 1건째가 이미 개봉한 메시지에 대해 실행되어 개봉 완료(400)로 거부된다
메시지의 삭제 `DeleteMessageByUserId`	1건으로 통합된다	실패한다	네임스페이스·사용자·메시지	계속 실패한다. 2건째는 이미 사라진 메시지에 대해 실행되어 찾을 수 없음(404)으로 거부된다

개봉과 삭제는 행이 다르고 경계가 같습니다. 한 통의 메시지를 같은 트랜잭션에서 개봉하고 삭제할 수는 없습니다. 메시지가 다르면 다른 대상이므로, 여러 메시지를 개봉하거나 삭제하는 것은 문제없습니다. 직렬 실행 모드(enableSequentialExecution 또는 TransactionSettingV2)를 활성화해도 이것은 불가능합니다. 둘 다 소비 액션이며 페이즈 안에서의 실행 순서는 액션 이름으로 결정되므로, DeleteMessageByUserId가 OpenMessageByUserId보다 반드시 먼저 실행됩니다. 개봉을 먼저 써도 순서는 바뀌지 않습니다. 개봉이 실행되는 시점에 메시지는 이미 존재하지 않으므로, 지금까지의 병합 충돌이 아니라 「찾을 수 없음」 오류로 실패합니다.

GS2-Inventory 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Inventory 고유의 내용입니다.

GS2-Inventory의 트랜잭션 액션은 4종류의 대상을 다룹니다.

아이템 : 네임스페이스·사용자·인벤토리·아이템 모델의 조합으로 결정됩니다. 그 아이템의 스택과 스택에 붙은 참조를 함께 보관합니다. 스택은 아이템 세트 이름으로 구별되는 한 덩어리로, 유효 기간을 나누고 싶은 경우 등에 하나의 아이템이 여러 스택을 가질 수 있습니다.
빅 아이템 : 같은 조합으로 결정됩니다. 일반 아이템보다 큰 수를 다룰 수 있는 보유 수를 하나 보관합니다. 아이템과는 이름이 같아도 다른 대상입니다.
심플 인벤토리 : 네임스페이스·사용자·인벤토리의 조합으로 결정됩니다. 하나 안에 모든 심플 아이템의 보유 수를 보관하지만, 기록은 아이템 이름별로 나뉩니다.
인벤토리의 용량 : 네임스페이스·사용자·인벤토리의 조합으로 결정됩니다. 최대 용량과 사용량을 별도로 보관합니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
아이템의 획득 `AcquireItemSetByUserId`	같은 스택이면 통합되어 개수가 합산된다. 다른 스택에 대한 획득을 나열하면 실패한다	실패한다	인벤토리·아이템 모델 (아이템)	성립한다. 같은 트랜잭션 안에서 다른 스택에 대한 획득을 나열한 경우도, 중첩을 넘어선 경우도 모두 실패하지 않게 된다. 각 액션이 직전 액션의 결과를 보고 실행되기 때문
아이템의 획득 (그레이드 지정) `AcquireItemSetWithGradeByUserId`	스택을 하나 만든다. 같은 아이템에 대한 두 번째는 조용히 버려진다	실패한다	인벤토리·아이템 모델 (아이템)	중첩을 넘어서도 성립한다. 다만 같은 트랜잭션 안의 경우와는 결과가 다르다. 1건으로 묶이지 않게 되므로, 같은 아이템에 대한 두 번째는 버려지지 않고 두 번째 스택을 만든다
아이템의 소비 `ConsumeItemSetByUserId`	통합되어 개수가 합산된다	실패한다	인벤토리·아이템 모델 (아이템)	성립한다. 중첩을 넘어서도 합산되며, 같은 아이템에 대한 획득과 같은 트랜잭션에 둘 수 있게 된다
참조의 추가 `AddReferenceOfByUserId`	스택과 참조 대상이 모두 같으면 통합된다. 한쪽이라도 다르면 실패한다	실패한다	인벤토리·아이템 모델 (아이템)	스택이나 참조 대상이 달라도, 중첩을 넘어서도 성립한다. 각 액션이 아이템을 매번 다시 읽으므로, 자신의 추가가 직전 액션의 쓰기 위에 쌓인다
참조의 삭제 `DeleteReferenceOfByUserId`	스택과 참조 대상이 모두 같으면 통합된다. 한쪽이라도 다르면 실패한다	실패한다	인벤토리·아이템 모델 (아이템)	참조의 추가와 같은 이유로, 스택이나 참조 대상이 달라도, 중첩을 넘어서도 성립한다
빅 아이템의 획득 `AcquireBigItemByUserId`	통합되어 개수가 합산된다	실패한다	인벤토리·아이템 모델 (빅 아이템)	성립한다. 중첩을 넘어서도 합산된다
빅 아이템의 소비 `ConsumeBigItemByUserId`	통합되어 개수가 합산된다	실패한다	인벤토리·아이템 모델 (빅 아이템)	성립한다. 중첩을 넘어서도 합산된다
빅 아이템의 설정 `SetBigItemByUserId`	같은 값이면 통합. 값이 다르면 발행 시에 오류	실패한다	인벤토리·아이템 모델 (빅 아이템)	중첩을 넘어서도 성립한다. 같은 값이면 통과하고, 값이 다르면 나중에 실행된 쪽의 값이 된다
심플 아이템의 획득·소비 `AcquireSimpleItemsByUserId` `ConsumeSimpleItemsByUserId`	혼재해도 된다. 아이템별로 통합되어 개수가 합산된다	합산된다	인벤토리·아이템 이름	변하지 않는다. 원래부터 합산되어 성립한다
심플 아이템의 설정 `SetSimpleItemsByUserId`	같은 값이면 통합. 값이 다르면 발행 시에 오류	실패한다	인벤토리·아이템 이름	같은 값이면 중첩을 넘어서도 성립한다. 값이 다른 경우는 계속 오류(400)다. 보유 수의 절대 지정이므로 나중에 실행된 쪽이 앞의 값을 조용히 덮어쓰는 것은 허용되지 않는다
용량의 가산 `AddCapacityByUserId`	통합되어 합산된다	합산된다	인벤토리·최대 용량	변하지 않는다. 원래부터 합산되어 성립한다
용량의 설정 `SetCapacityByUserId`	같은 값이면 통합. 값이 다르면 발행 시에 오류	실패한다	인벤토리·최대 용량	중첩을 넘어서도 성립한다. 같은 값이면 통과하고, 값이 다르면 나중에 실행된 쪽의 값이 된다
보유 수의 검증 `VerifyItemSetByUserId` `VerifySimpleItemByUserId` `VerifyBigItemByUserId`	`multiplyValueSpecifyingQuantity`를 지정하지 않으면, 검증 타입이 `greater` `greaterEqual`일 때 임계값이 합산되고, `less` `lessEqual` `equal` `notEqual`은 완전히 같은 검증이 1건으로 묶인다. 명시적으로 지정한 경우에는 검증 타입에 관계없이 그 지정을 따른다	읽기만 하므로 충돌하지 않는다	인벤토리·아이템 모델·아이템 세트 (지정할 수 있는 액션의 경우)·검증 타입	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다
용량의 검증 `VerifyInventoryCurrentMaxCapacityByUserId`	완전히 같은 검증은 1건으로 묶인다	읽기만 하므로 충돌하지 않는다	인벤토리·검증 타입·임계값	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다
참조의 검증 `VerifyReferenceOfByUserId`	완전히 같은 검증은 1건으로 묶인다. 임계값을 갖지 않으므로 항상 이 취급	읽기만 하므로 충돌하지 않는다	아이템·검증 타입·참조 대상	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다

그레이드를 지정한 획득은 같은 아이템에 대해 1 트랜잭션당 1건까지로 해 주십시오. 이 액션은 개수를 갖지 않으며, 같은 아이템에 대한 두 번째는 오류가 되지 않은 채 버려집니다. 아이템이 다르면 각각 실행됩니다.

GS2-JobQueue 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-JobQueue 고유의 내용입니다.

GS2-JobQueue의 트랜잭션 액션은 네임스페이스와 사용자의 조합으로 결정되는 한 사용자의 잡 큐를 대상으로 합니다. 등록은 항상 새로운 잡을 만들므로 등록마다 다른 대상이 되고, 삭제는 잡 이름으로 특정되는 기존 잡 하나를 대상으로 합니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
잡의 등록 `PushByUserId`	1건의 등록으로 통합되어 잡의 리스트가 연결된다. 합계가 10건을 넘으면 발행 시에 오류가 된다	충돌하지 않는다. 등록할 때마다 자신의 잡을 만든다	등록할 때마다 다른 대상	변하지 않는다. 원래부터 충돌하지 않는다
잡의 삭제 `DeleteJobByUserId`	1건으로 통합된다	실패한다	네임스페이스·사용자·잡 이름	계속 실패한다. 1건으로 묶이지 않게 되므로, 2건째는 이미 사라진 잡에 대해 실행되어 찾을 수 없음(404)으로 거부된다

트랜잭션에서 등록한 잡은 그 트랜잭션의 다른 액션에서는 아직 존재하지 않는 것으로 취급됩니다. 모든 액션이 트랜잭션 시작 시점의 상태를 기준으로 동작하기 때문입니다. 잡을 쌓은 뒤 조작하고 싶은 경우에는 트랜잭션을 나누어 주십시오.

GS2-Limit 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Limit 고유의 내용입니다.

GS2-Limit의 트랜잭션 액션은 네임스페이스·사용자·횟수 제한 종류·카운터 이름의 조합으로 결정되는 하나의 카운터를 대상으로 합니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
카운트업·카운트다운 `CountUpByUserId` `CountDownByUserId`	혼재해도 된다. 통합되어 값이 합산된다. 다만 `maxValue`가 다른 카운트업을 나열하면 발행 시에 오류	합산된다	네임스페이스·사용자·횟수 제한 종류·카운터 이름	변하지 않는다. 원래부터 합산되어 성립한다
카운터의 삭제 `DeleteCounterByUserId`	1건으로 통합된다	실패한다	네임스페이스·사용자·횟수 제한 종류·카운터 이름	성립한다. 중첩을 넘어서도 1건으로 통합되며, 같은 트랜잭션에서 카운트업과 함께 둘 수 있게 된다(아래 참조)
검증 `VerifyCounterByUserId`	완전히 같은 검증은 1건으로 묶인다. `multiplyValueSpecifyingQuantity`를 명시적으로 `true`로 했을 때만 임계값이 합산된다 (검증 타입은 무관. 임계값을 「1개당 수량」으로 선언한 것이 되기 때문). 횟수가 다른 검증은 각각 판정된다	읽기만 하므로 충돌하지 않는다	카운터·검증 타입·횟수	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다

카운트업과 카운트다운이 같은 행인 것은, 둘 다 같은 값에 대한 순수한 증분으로 기록되기 때문입니다. 혼재시켜도 됩니다. 결과는 통합 후의 합계에 대해 판정됩니다. 카운트는 0을 밑돌 수 없고 횟수 제한 종류에 설정된 상한도 넘을 수 없으므로, 단독으로는 들어가는 카운트업이라도 다른 카운트업과 합쳐지면 거부될 수 있습니다.

GS2-LoginReward 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-LoginReward 고유의 내용입니다.

GS2-LoginReward의 트랜잭션 액션은 네임스페이스·사용자·보너스 모델의 조합으로 결정되는 하나의 수령 상황을 대상으로 합니다. 어떤 스텝을 수령했는지를 목록을 통째로 가지는 한 행으로 기록합니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
스텝의 수령 완료 마크 `MarkReceivedByUserId`	같은 스텝이면 하나로 합쳐짐. 스텝이 다르면 오류 (400)	같은 스텝이면 통과. 스텝이 다르면 실패한다	네임스페이스·사용자·보너스 모델	스텝이 달라도 성립한다. 나중에 실행된 쪽이 이미 기록된 목록을 읽은 뒤 자신의 스텝을 추가하므로 양쪽 스텝이 모두 마크된다
마크의 취소 `UnmarkReceivedByUserId`	같은 스텝이면 하나로 합쳐짐. 스텝이 다르면 오류 (400)	같은 스텝이면 통과. 스텝이 다르면 실패한다	네임스페이스·사용자·보너스 모델	스텝이 달라도 성립한다. 나중에 실행된 쪽이 이미 기록된 목록을 읽은 뒤 자신의 스텝을 제거하므로 양쪽 취소가 모두 반영된다
수령 상황의 파기 `DeleteReceiveStatusByUserId`	1건으로 통합된다	실패한다	네임스페이스·사용자·보너스 모델	중첩을 넘어서도 성립한다. 1건으로 통합되지는 않지만, 이미 파기된 수령 상황을 다시 파기하는 경우에는 새로 만든 뒤 파기할 뿐이다

여러 스텝을 하나의 트랜잭션에서 수령하지 마십시오. 수령 완료 스텝의 목록은 한 행에 모여 있어 전체가 다시 쓰이므로, 경계를 스텝 단위로 나눌 수 없습니다. 그 때문에 다른 스텝에 대한 마크를 두 개 나열하면 합성할 수 없어, 트랜잭션을 구성하는 시점에 오류 (400) 가 됩니다. 같은 스텝에 대한 마크는 하나로 합쳐집니다. 스텝별로 트랜잭션을 나누어 주십시오.

GS2-Lottery 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Lottery 고유의 내용입니다.

GS2-Lottery가 트랜잭션에 지정할 수 있는 액션은 2가지입니다. 추첨은 하나씩, 당첨된 경품을 산출하여 그것을 자신의 트랜잭션으로 발행합니다. 10연 추첨이라면 10개의 안쪽 트랜잭션이 됩니다. GS2-Lottery를 사용할 때 가장 주의가 필요한 것이 이 점으로, 아래의 「경품이 배분하는 것」에 정리했습니다.

GS2-Lottery 자체 안에서 무엇을 건드리는지는 경품 테이블의 종류에 따릅니다. 일반 경품 테이블은 사용자별 상태를 갖지 않지만, 박스 경품 테이블은 네임스페이스·사용자·경품 테이블의 조합으로 결정되는 박스를 가집니다.

GS2-Matchmaking 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Matchmaking 고유의 내용입니다.

GS2-Matchmaking이 트랜잭션에 지정할 수 있는 액션은 1가지이며, 읽기만 수행합니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
참가하고 있음의 검증 `VerifyIncludeParticipantByUserId`	완전히 같은 검증은 1건으로 묶인다	읽기만 하므로 충돌하지 않는다	시즌 개더링·검증 타입·대상 사용자	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다

다른 검증 액션과 마찬가지로, 이 액션도 트랜잭션 시작 시점의 시즌 개더링을 봅니다. 같은 트랜잭션 안에서 개더링에 참가한 사용자는 이 판정에서는 아직 참가자가 아닙니다. 그 때문에 참가시킨 뒤 그 참가를 검증하는 흐름을 하나의 트랜잭션으로 수행할 수는 없습니다.

GS2-Mission 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Mission 고유의 내용입니다.

GS2-Mission의 트랜잭션 액션은 2종류의 대상을 다룹니다.

카운터 : 네임스페이스·사용자·카운터 이름의 조합으로 결정됩니다. 리셋 종별마다 하나씩 값을 보관합니다.
미션 그룹의 진행 상황 : 네임스페이스·사용자·미션 그룹의 조합으로 결정됩니다. 어떤 태스크를 달성했는지, 어떤 보상을 수령했는지를 태스크 단위로 보관합니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
카운터의 가산 `IncreaseCounterByUserId`	통합되어 값이 합산된다	합산된다	네임스페이스·사용자·카운터 이름	변하지 않는다. 원래부터 합산되어 성립한다
카운터의 감산 `DecreaseCounterByUserId`	통합되어 값이 합산된다	실패한다	네임스페이스·사용자·카운터 이름	성립한다. 중첩을 넘어서도 합산된다
카운터의 리셋 `ResetCounterByUserId`	스코프가 결합되어 1건이 된다. 합계가 20 스코프를 넘으면 결합을 중단하고 두 번째 이후가 조용히 버려진다	실패한다	네임스페이스·사용자·카운터 이름	성립한다. 안쪽에서 도착하는 리셋은 바깥쪽이 이미 기록한 상태 위에 적용된다. 두 건이 하나의 액션으로 결합되는 것은 아니므로 20 스코프 결합 규칙은 여기에 해당하지 않는다
카운터의 설정 `SetCounterByUserId`	같은 값이면 통합. 값이 다르면 발행 시에 오류	실패한다	네임스페이스·사용자·카운터 이름	중첩을 넘어서도 성립한다. 같은 값이면 통과하고, 값이 다르면 나중에 실행된 쪽의 값이 된다
보상의 수령 `ReceiveByUserId` `BatchReceiveByUserId`	1건으로 묶이며 태스크 이름이 중복을 제외하고 결합된다	실패한다	네임스페이스·사용자·미션 그룹	성립한다. 안쪽에서 도착하는 수령은 바깥쪽이 이미 기록한 상태 위에 적용된다
수령의 취소 `RevertReceiveByUserId`	같은 태스크이면 통합. 태스크가 다르면 발행 시에 오류	실패한다	네임스페이스·사용자·미션 그룹	같은 태스크든 다른 태스크든 중첩을 넘어서면 성립한다. 각각이 직전의 쓰기 위에 적용된다. 다른 태스크의 취소를 하나의 트랜잭션에 나란히 작성한 경우의 거부는 발행 시에 작동하므로 변하지 않는다
검증 액션 전반	완전히 같은 검증은 1건으로 묶인다. `VerifyCounterValueByUserId`는 임계값이 다른 경우에만 양쪽이 판정된다	읽기만 하므로 충돌하지 않는다	대상·검증 타입·임계값	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다

카운터는 가산만이 순수한 증분으로 기록되고, 그 외에는 카운터 전체를 다시 씁니다. 그래서 가산은 중첩 너머에서도 합류하지만, 감산·리셋·설정은 경계가 같은 다른 행과 함께 둘 수 없습니다. 감산끼리 문제없는 것은 실행 전에 하나의 감산으로 통합되기 때문입니다. 직렬 실행 모드(enableSequentialExecution 또는 TransactionSettingV2)를 활성화하면 이 제약의 일부가 사라집니다. 같은 카운터에 대한 감산·리셋·설정은 하나의 트랜잭션에 넣을 수 있게 됩니다. 모두 카운터 전체를 다시 쓰며, 각각이 직전 액션의 쓰기를 볼 수 있기 때문입니다. 실행 순서는 액션 이름으로 결정되므로 감산이 리셋보다 먼저, 설정이 마지막에 실행되어 그때까지의 결과를 덮어씁니다. 가산만은 다릅니다. 가산은 카운터 전체의 재작성이 아니라 하나의 카운터 값에 대한 증분으로 기록되므로, 같은 카운터에 대한 감산·리셋·설정과 함께 두는 것은 계속 불가능합니다.

GS2-Money 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Money 고유의 내용입니다.

GS2-Money의 트랜잭션 액션은 2종류의 대상을 다룹니다.

월렛 : 네임스페이스·사용자·슬롯의 조합으로 결정됩니다. 업데이트할 때마다 전체가 다시 쓰입니다.
영수증 : 영수증에서 추출한 거래 ID로 결정됩니다. 1건의 과금을 기록합니다. 하나의 트랜잭션에 사용자당 1건만 놓을 수 있습니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
월렛에의 가산 `DepositByUserId`	같은 가격이면 통합되어 수가 합산된다. 가격이 다른 가산은 실패한다	실패한다	네임스페이스·사용자·슬롯	가격이 달라도, 중첩을 넘어서도 성립한다. 각 가산이 직전의 쓰기를 반영한 월렛을 다시 읽은 뒤 다시 쓰므로, 나중에 실행되는 가산의 쓰기에는 이미 앞선 가격 항목이 포함되어 있다
월렛에서의 감산 `WithdrawByUserId`	통합되어 수가 합산된다	실패한다	네임스페이스·사용자·슬롯	성립한다. 중첩을 넘어서도 합산된다
영수증의 기록 `RecordReceipt`	실패한다	같은 영수증이면 실패한다	네임스페이스·사용자(행 자체는 영수증 단위)	같은 영수증이면 계속 실패한다. 기록은 영수증이 아직 기록되지 않았음을 확인하므로, 직렬 실행에서는 2건째가 1건째가 기록한 행을 읽고 중복(400)으로 거부된다. 오류가 되는 시점이 달라질 뿐이다. 같은 트랜잭션 내의 거부는 변하지 않는다. 이는 어떤 액션도 실행되기 전, 발행 시에 작동하기 때문이다
영수증 기록의 취소 `RevertRecordReceipt`	실패한다	실패하지 않는다	네임스페이스·사용자(행 자체는 영수증 단위)	중첩을 넘어서는 지금까지 통과하던 것이 실패하게 된다. 2건째의 취소는 이미 사라진 영수증 기록에 대해 실행되어 찾을 수 없음(404)으로 거부된다

같은 사용자에 대한 영수증 기록끼리, 취소끼리는 영수증이 다르더라도 발행 시점에 오류가 됩니다. 영수증은 거래 ID를 거쳐 행에 도달하는데, 거래 ID를 추출하는 방법이 스토어마다 다르기 때문에 겉보기에 다른 영수증이 같은 과금을 가리키는 경우가 있습니다. 추측으로 합치지 않고, 하나의 트랜잭션에 1건만 놓아 주십시오. 영수증을 기록하는 진열 상품을 수량 2 이상으로 구입한 경우에도 액션이 개수만큼 쌓이므로 여기에 해당합니다.

GS2-Money2 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Money2 고유의 내용입니다.

GS2-Money2의 트랜잭션 액션은 네임스페이스·사용자·슬롯의 조합으로 결정되는 하나의 월렛을 대상으로 합니다. 월렛은 유상 잔액과 무상 잔액을 함께 보관합니다.

무상 잔액만 움직이는 업데이트는 증분으로 기록되므로 합산됩니다. 유상 잔액이 움직이는 업데이트는 월렛 전체를 다시 씁니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
무상 통화만 움직이는 입금·출금 `DepositByUserId` `WithdrawByUserId`	혼재해도 된다. 통합되어 금액이 합산된다	합산된다	네임스페이스·사용자·슬롯	변하지 않는다. 원래부터 합산되어 성립한다
유상 통화가 움직이는 입금·출금 `DepositByUserId` `WithdrawByUserId`	입금은 입금 트랜잭션이 하나의 리스트로 묶이고, 출금은 금액이 합산된다. 입금과 출금의 공존은 실패한다	실패한다	네임스페이스·사용자·슬롯	입금과 출금의 공존을 포함해, 중첩을 넘어서도 성립한다. 각 액션이 직전의 쓰기를 반영한 월렛을 다시 읽은 뒤 다시 쓰므로, 나중에 실행되는 쪽에는 이미 앞선 쓰기가 반영되어 있다
영수증의 검증 `VerifyReceiptByUserId`	실패한다	같은 거래 ID로 해석되면 실패한다	네임스페이스·사용자(행 자체는 거래 ID 단위)	같은 거래 ID에서의 중첩 충돌은 성립한다. 기록은 아직 존재하지 않는 행에만 기록되므로, 안쪽과 바깥쪽의 기록이 같은 1건으로 통합되게 된다. 같은 트랜잭션 내의 거부는 변하지 않는다. 이는 어떤 액션도 실행되기 전, 발행 시에 작동하기 때문이다

무상 통화의 업데이트는 증분이므로, 무상의 입금과 출금을 하나의 트랜잭션에 넣어도 양쪽이 적용됩니다. 유상 잔액이 움직이는 경우에는 월렛 전체가 다시 쓰이므로 두 개의 행을 함께 둘 수 없습니다.직렬 실행 모드(enableSequentialExecution 또는 TransactionSettingV2)를 활성화하면 두 번째 행에 대해서도 이 제약은 사라집니다. 입금과 출금 중 나중에 실행되는 쪽이 먼저 실행된 쪽이 남긴 그대로의 월렛을 읽으므로, 유상 잔액이 움직이는 경우에도 하나의 트랜잭션에 넣을 수 있게 됩니다.

GS2-Quest 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Quest 고유의 내용입니다.

GS2-Quest가 트랜잭션에 지정할 수 있는 액션은 2가지이며, 둘 다 네임스페이스와 사용자의 조합으로 결정되는 한 사용자의 진행을 대상으로 합니다. 진행은 사용자당 하나만 존재하며, 이것이 플레이어를 동시에 하나의 퀘스트로 제한하는 구조입니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
진행의 생성 `CreateProgressByUserId`	완전히 동일한 지정이라도 발행 시에 오류	실패한다	네임스페이스·사용자	파기와의 충돌은 계속 실패한다. 파기는 소비 액션이므로 먼저 실행되어 생성의 존재 확인 자체는 통과하지만, 파기와 생성은 같은 행에 대한 두 개의 쓰기가 되어 이를 하나로 묶을 수 없으므로 트랜잭션이 실패한다(400). 애초에 생성과 파기를 하나의 트랜잭션에 직접 나열하는 것 자체가 발행 시에 거부된다. 생성끼리의 충돌도 변하지 않고 계속 실패한다. 나중에 실행되는 쪽은 진행이 이미 존재하는 상태를 보게 되어 자신의 생성 조건이 성립하지 않으므로, 값이 일치하지 않아서가 아니라 이 이유로 계속 실패한다
진행의 파기 `DeleteProgressByUserId`	완전히 동일한 지정이라도 발행 시에 오류	1건으로 통합된다	네임스페이스·사용자	중첩을 넘어서는 1건으로 통합되지 않게 되어 실패하게 된다. 2건째의 파기는 이미 사라진 진행에 대해 실행되어 찾을 수 없음(404)으로 거부된다

생성과 파기는 행이 다르고 경계가 같습니다. 진행의 유무와 관계없이 하나의 트랜잭션에 넣을 수는 없습니다. 발행 시에 오류가 됩니다.

GS2-Ranking2 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Ranking2 고유의 내용입니다.

GS2-Ranking2의 트랜잭션 액션은 2종류의 대상을 다룹니다. 시즌 보상의 수령을 기록한 것과, 검증 액션이 읽는 스코어입니다. 기록은 랭킹과 시즌별로 나뉘므로, GS2-Ranking2의 액션끼리 충돌하는 일은 거의 없습니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
수령의 기록 `CreateGlobalRankingReceivedRewardByUserId` `CreateClusterRankingReceivedRewardByUserId`	1건으로 통합된다	실패한다	네임스페이스·사용자·랭킹·시즌·클러스터	계속 실패한다. 기록은 아직 존재하지 않는 경우에만 기록되며, 안쪽과 바깥쪽의 기록을 1건으로 묶으면 그 보호가 사라지므로 묶지 않고 오류(400)가 된다
스코어의 검증 `VerifyGlobalRankingScoreByUserId` `VerifyClusterRankingScoreByUserId` `VerifySubscribeRankingScoreByUserId`	임계값이 같은 것은 1건으로 묶이고, 다른 것은 각각 판정된다	읽기만 하므로 충돌하지 않는다	랭킹·시즌·검증 타입	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다

기록은 아직 존재하지 않는 경우에만 기록됩니다. 이것이 시즌 보상을 이중으로 수령하지 못하게 하는 구조입니다. 이미 기록된 수령을 다시 기록하는 것은, 같은 트랜잭션에서든 이후의 트랜잭션에서든 실패합니다.

GS2-Schedule 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Schedule 고유의 내용입니다.

GS2-Schedule의 트랜잭션 액션은 네임스페이스·사용자·트리거 이름의 조합으로 결정되는 하나의 트리거를 대상으로 합니다. 트리거는 업데이트할 때마다 전체가 다시 쓰입니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
트리거를 당기기 `TriggerByUserId`	1건으로 통합된다	실패한다	네임스페이스·사용자·트리거 이름	중첩을 넘어서도 성립한다. 다만 1건으로 통합되지는 않는다. 2건째는 1건째가 남긴 트리거에 대해 실행되어 자신의 `triggerStrategy`를 적용한다
트리거의 연장 `ExtendTriggerByUserId`	통합되어 초 수가 합산된다	실패한다	네임스페이스·사용자·트리거 이름	중첩을 넘어서도 성립한다. 2건째는 1건째가 남긴 기한에 대해 실행되므로 결과적으로 초 수는 합산된다
트리거의 삭제 `DeleteTriggerByUserId`	1건으로 통합된다	실패한다	네임스페이스·사용자·트리거 이름	계속 실패한다. 1건으로 묶이지 않게 되므로, 2건째는 이미 사라진 트리거에 대해 실행되어 찾을 수 없음(404)으로 거부된다
트리거의 검증 `VerifyTriggerByUserId`	완전히 같은 검증은 1건으로 묶인다	읽기만 하므로 충돌하지 않는다	트리거·검증 타입·경과 시간	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다
이벤트의 검증 `VerifyEventByUserId`	완전히 같은 검증은 1건으로 묶인다	읽기만 하므로 충돌하지 않는다	이벤트·검증 타입·사용자	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다

당기기·연장하기·삭제하기는 세 개의 다른 행이며 경계가 같습니다. 이 중 두 개를 하나의 트리거에 대해 지정하면 충돌합니다. 트리거를 당긴 뒤 연장하고 싶다는 요구는 흔하지만, 여기에는 트랜잭션이 두 개 필요합니다. 연장은 트랜잭션 시작 시점의 상태에서 움직이므로, 같은 트랜잭션이 당긴 트리거가 보이지 않기 때문입니다. 직렬 실행 모드(enableSequentialExecution 또는 TransactionSettingV2)를 활성화하면 당기기와 연장하기를 하나의 트랜잭션에 넣을 수 있게 됩니다. 다만 순서는 기대와 다릅니다. 페이즈 안에서의 실행 순서는 액션 이름으로 결정되므로 ExtendTriggerByUserId가 TriggerByUserId보다 반드시 먼저 실행됩니다. 트리거가 아직 없으면 연장이 트리거를 만들고, 그 위에 당기기가 자신의 triggerStrategy를 적용합니다. 당긴 뒤 그 결과를 같은 트랜잭션에서 연장할 수는 없습니다. 삭제와 당기기·연장하기의 조합은 해소되지 않습니다. 삭제는 소비 액션으로 먼저 실행되지만, 하나의 트랜잭션에서 트리거를 지웠다가 다시 만드는 것은 같은 행에 대한 두 개의 쓰기가 되어 묶이지 않고 오류(400)가 됩니다.

GS2-Script 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Script 고유의 내용입니다.

GS2-Script가 트랜잭션에 지정할 수 있는 액션은 1가지입니다. GS2-Script 자체는 사용자별 상태를 갖지 않으므로, 이 액션이 GS2-Script를 이유로 다른 것과 충돌하는 일은 없습니다. 무엇과 충돌할 수 있는지는 스크립트가 무엇을 하는지에 따라 결정됩니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
스크립트의 실행 `InvokeScript`	통합되지 않고 각각 독립적으로 실행된다	통합되지 않고 각각 독립적으로 실행된다	실행할 때마다 다른 대상	변하지 않는다. 각각 독립적으로 실행되는 것은 동일하다

스크립트·사용자·인수·난수 시드가 완전히 같은 실행을 여러 개 지정한 경우에도 각각 독립적으로 실행됩니다. 다만 acquireActionUseJobQueue를 활성화하여 작업 큐 경유로 실행하는 경우에는 완전히 같은 실행이 한 번으로 통합될 수 있습니다.

GS2-SerialKey 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-SerialKey 고유의 내용입니다.

GS2-SerialKey의 트랜잭션 액션은 네임스페이스와 시리얼 코드의 조합으로 결정되는 하나의 시리얼 키를 대상으로 합니다. 시리얼 키는 사용 완료 여부와 누가 사용했는지를 기록하는 것으로, 업데이트할 때마다 전체가 다시 쓰입니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
키의 사용 `UseByUserId`	완전히 같은 지정이라도 발행 시에 오류	실패한다	네임스페이스·코드	같은 키에 대한 사용끼리는 변하지 않는다. 이 거부는 어떤 액션도 실행되기 전, 발행 시에 작동하기 때문이다. 취소와의 충돌도 직접 나열한 경우든 중첩에서 도착한 경우든 해소되지 않는다(후술)
사용의 취소 `RevertUseByUserId`	완전히 같은 지정이라도 발행 시에 오류	실패한다	네임스페이스·코드	같은 키에 대한 취소끼리는 같은 이유로 변하지 않는다. 사용과의 충돌도 해소되지 않는다(후술)
키의 발행 `IssueOnce`	각각이 새로운 키를 발행한다. 충돌하지 않는다	충돌하지 않는다	발행할 때마다 다른 대상	변하지 않는다. 원래부터 충돌하지 않는다
코드의 검증 `VerifyCodeByUserId`	완전히 같은 검증은 1건으로 묶인다	읽기만 하므로 충돌하지 않는다	코드·검증 타입·사용자·캠페인	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다

사용과 취소는 행이 다르고 경계가 같습니다. 하나의 키를 같은 트랜잭션에서 사용하고 취소할 수는 없습니다. 키가 다르면 다른 대상이므로, 여러 키를 사용하는 것은 문제없습니다. 같은 키에 대한 취소를 하나의 트랜잭션에 2건 놓은 경우에도 사용과 마찬가지로 발행 시에 오류가 됩니다. 하나의 트랜잭션에 2건 나열할 용도가 없는 데다, 1건째에서 미사용으로 되돌아간 이상 2건째는 반드시 실패하기 때문입니다.직렬 실행 모드(enableSequentialExecution 또는 TransactionSettingV2)를 활성화해도 이 조합은 성립하지 않습니다. 사용은 소비 액션으로 취소(획득 액션)보다 먼저 실행되므로 취소 자신의 확인은 통과합니다. 그러나 두 건은 같은 트랜잭션에서 키의 상태를 반대 값으로 기록하게 되어, 하나로 묶이지 않아 트랜잭션이 실패합니다(400). 같은 키에 대한 취소를 2건 놓았을 때의 발행 시 오류는 변하지 않습니다. 이는 트랜잭션 발행 시에 작동하는 거부이기 때문입니다.

GS2-Showcase 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Showcase 고유의 내용입니다.

GS2-Showcase의 트랜잭션 액션은 네임스페이스·사용자·진열대의 조합으로 결정되는 하나의 진열 상태를 대상으로 합니다. 진열 상태는 어떤 상품이 진열되어 있는지와 상품별 구매 횟수를 보관합니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
구매 횟수의 가산·감산 `IncrementPurchaseCountByUserId` `DecrementPurchaseCountByUserId`	혼재해도 된다. 상품별로 통합되어 값이 합산된다. 다른 상품끼리는 영향을 주지 않는다	합산된다	네임스페이스·사용자·진열대	변하지 않는다. 원래부터 합산되어 성립한다
진열의 다시 뽑기 `ForceReDrawByUserId`	통합되어 다시 뽑기는 한 번만 수행된다	실패한다	네임스페이스·사용자·진열대	중첩을 넘어서도 성립한다. 다만 같은 트랜잭션 안과는 달리 다시 뽑기는 두 번 수행된다. 1건으로 묶이지 않게 되므로, 플레이어에게 보이는 진열은 나중에 실행된 다시 뽑기의 결과가 된다

구매 횟수는 상품별로 기록되므로 다른 상품의 횟수끼리 충돌하는 일은 없습니다. 횟수는 그 상품에 설정된 상한 이하여야 하고 0을 밑돌 수 없습니다. 통합 후의 합계에 대해 판정되므로, 단독으로는 들어가는 가산이라도 다른 가산과 합쳐지면 거부될 수 있습니다.

GS2-SkillTree 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-SkillTree 고유의 내용입니다.

GS2-SkillTree의 트랜잭션 액션은 네임스페이스·사용자·프로퍼티의 조합으로 결정되는 하나의 스테이터스를 대상으로 합니다. 스테이터스는 스킬 트리의 어떤 노드를 해방했는지를 기록하는 것으로, 업데이트할 때마다 전체가 다시 쓰입니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
노드의 해방 `MarkReleaseByUserId`	통합되어 노드 이름이 중복을 제외하고 결합된다	실패한다	네임스페이스·사용자·프로퍼티	성립한다. 안쪽에서 도착하는 해방은 바깥쪽이 이미 기록한 상태 위에 적용된다
노드의 억제 `MarkRestrainByUserId`	통합되어 노드 이름이 중복을 제외하고 결합된다	실패한다	네임스페이스·사용자·프로퍼티	성립한다. 안쪽에서 도착하는 억제는 바깥쪽이 이미 기록한 상태 위에 적용된다

노드의 해방에는 그 노드가 필요로 하는 것의 지불이 따르며, 억제하면 그것이 반환됩니다. 이러한 지불과 반환은 자신의 트랜잭션으로 발행되므로, 그것들이 속한 서비스의 제한을 받습니다.

GS2-Stamina 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-Stamina 고유의 내용입니다.

GS2-Stamina의 트랜잭션 액션은 네임스페이스·사용자·스태미나 모델의 조합으로 결정되는 하나의 스태미나를 대상으로 합니다. 스태미나는 스태미나 값·최대값·회복 간격·회복량·초과값을 함께 보관하지만, 각 액션은 자신이 실제로 변경하는 값만 기록하므로 변경하는 값이 다르면 다른 대상이 됩니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
스태미나 값의 회복·소비 `RecoverStaminaByUserId` `ConsumeStaminaByUserId`	통합된다. 합산한 값으로 판정된다	합산된다. 다만 회복의 합계가 자연 회복으로 도달할 수 있는 범위를 넘으면 충돌(409)이 되며, 재시도로는 해소되지 않습니다	네임스페이스·사용자·스태미나 모델·스태미나 값	변하지 않는다. 충돌이 되는 경우를 포함해 동작은 동일하다
최대값의 가산·감산 `RaiseMaxValueByUserId` `DecreaseMaxValueByUserId`	통합된다. 합산한 값으로 판정된다	합산된다	네임스페이스·사용자·스태미나 모델·최대값	변하지 않는다. 원래부터 합산되어 성립한다
최대값의 설정 `SetMaxValueByUserId`	같은 값이면 통합. 값이 다르면 발행 시에 오류	실패한다	네임스페이스·사용자·스태미나 모델·최대값	같은 값이면 중첩을 넘어서도 성립한다. 값이 다른 경우는 계속 오류(400)다. 값의 절대 지정이므로 나중에 실행된 쪽이 앞의 값을 조용히 덮어쓰는 것은 허용되지 않는다
회복 간격의 설정 `SetRecoverIntervalByUserId`	같은 값이면 통합. 값이 다르면 발행 시에 오류	실패한다	네임스페이스·사용자·스태미나 모델·회복 간격	같은 값이면 중첩을 넘어서도 성립한다. 값이 다른 경우는 계속 오류(400)다. 값의 절대 지정이므로 나중에 실행된 쪽이 앞의 값을 조용히 덮어쓰는 것은 허용되지 않는다
회복량의 설정 `SetRecoverValueByUserId`	같은 값이면 통합. 값이 다르면 발행 시에 오류	실패한다	네임스페이스·사용자·스태미나 모델·회복량	같은 값이면 중첩을 넘어서도 성립한다. 값이 다른 경우는 계속 오류(400)다. 값의 절대 지정이므로 나중에 실행된 쪽이 앞의 값을 조용히 덮어쓰는 것은 허용되지 않는다
검증 액션 전반	`multiplyValueSpecifyingQuantity`를 지정하지 않으면, 검증 타입이 `greater` `greaterEqual`일 때는 임계값이 합산된 하나의 조건이 되고, `less` `lessEqual` `equal` `notEqual`은 완전히 같은 검증이 1건으로 묶일 뿐이다. 명시적으로 지정한 경우에는 검증 타입에 관계없이 그 지정을 따른다	읽기만 하므로 충돌하지 않는다	네임스페이스·사용자·스태미나 모델·검증 타입	변하지 않는다. 읽기만 하므로 원래 충돌하지 않는다

최대값의 행은 두 개이며 경계가 같으므로 함께 둘 수 없습니다. 설정과 가산·감산을 하나의 트랜잭션에 넣으면 실패합니다. 직렬 실행 모드(enableSequentialExecution 또는 TransactionSettingV2)를 활성화하면 액션이 한 건씩 실행되고 각 액션이 직전 액션의 쓰기를 볼 수 있게 되므로 이 제약이 사라집니다. 최대값의 설정과 가산·감산을 하나의 트랜잭션에 넣을 수 있게 됩니다. 결과는 정규화된 실행 순서로 나중에 실행된 액션에 의해 결정됩니다(작성한 순서가 아닙니다). 설정이 나중이면 절대값으로 그대로 덮어쓰고, 가산·감산이 나중이면 다른 액션이 남긴 값에 대한 증감이 됩니다.

GS2-StateMachine 트랜잭션 액션

Mon, 01 Jan 0001 00:00:00 +0000

액션의 조합과 동시 실행

모든 서비스에 공통되는 전제는 트랜잭션 액션의 조합에 정리되어 있습니다. 먼저 그쪽을 읽어 주십시오. 이 절의 나머지는 GS2-StateMachine 고유의 내용입니다.

GS2-StateMachine이 트랜잭션에 지정할 수 있는 액션은 1가지입니다. 스테이트 머신의 시작은 매번 새로운 스테이터스를 만들므로, 대상을 다투는 일이 없습니다.

조작	같은 행을 겹쳤을 때	중첩 너머	다른 대상이 되는 경계	직렬 실행 모드 활성화 시
스테이트 머신의 시작 `StartStateMachineByUserId`	각각이 자신의 스테이트 머신을 시작한다. 충돌하지 않는다	충돌하지 않는다	시작할 때마다 다른 대상	변하지 않는다. 원래부터 충돌하지 않는다

진행 중인 스테이트 머신의 각 스텝도 각각 독립된 트랜잭션이므로, 시작한 트랜잭션과 통합되는 일은 없습니다. 스테이트 머신이 스텝 안에서 무엇을 하는지는 건드리는 서비스의 제한을 받습니다.