Avoiding (or reducing) concurrent writes on the same key

[rupc]

Multiple participants subscribing to the same lottery event concurrently incur a write contention on the same key on the ledger. In chaincode implementation, multiple transactions which write on the same key at the same time incur rejection on all transactions except one.
The problem of multiple write operations on the same key in this application is essential and unavoidable because a demanding deployment scenario includes this. For example, when there are many people in a room, and they are trying to participate in the same lottery event at the almost same time, simultaneous multiple writes should be appropriately handled.

Possible solutions

• Serialize the requests: Tried, but this slowdown throughput significantly. It must be used with batching.
• Batch the requests: Batching requests(e.g., periodic timeout ) on the same lottery is a good solution, but it increases latency and adds some complexity of implementation(i.e., maintaining client connections, and message queue, at which fetches requests from).
• Re-design application data model: Representing a lottery abstraction as a single key in the chaincode implementation is an evil root of this problem. But, Hyperledger/Fabric developers mostly seemed to use this kind of model to represent their application data structure because the common example applications do like this. An alternative approach may include dot representation: lotteryHash.targetBlockHash, or lotteryHash.participantList.

Actually, at the moment, there seemed no decent solution for this because this problem had come from a design of Hyperledger/Fabric(i.e., Execute/Order/Validate)