Re: How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications
you don't have to write to the same key.
You can have each voter / bidder commit to his vote / bid by writing to a separate key that corresponds to its identity, and in the end have all the voters / bidders reveal their votes / bids, and this will not create any MVCC conflicts.
From: "Mr.Phuwanai Thummavet" <mr.thummavet@...>
Date: 10/23/2019 12:16 PM
Subject: [EXTERNAL] [Hyperledger Fabric] How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications
Sent by: fabric@...
I know that the multi-version concurrency control (MVCC) is used to address double-spending problems in Fabric. However, the MVCC might become one of the most obstacles when designing time-critical applications such as auction and voting systems. On a voting system, for example, two voters commit to voting for the same candidate in the same block-time frame. This results in an invalid transaction for the 2nd voter according to the MVCC.
My solution to such an issue was to use an off-chain messaging queue system to gather and categorize certain transaction requests from clients. Then, the batches of the categorized transactions were sent to a chaincode to invoke.
Here are my questions:
1. Was my solution suitable for the above example?
2. Does anyone have better solutions?
3. Is Hyperledger Fabric suitable for real-time applications such as auction and voting systems?