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@...>
To:
fabric@...
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@...
Hi everyone,
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?
Thanks.
--
Best Regards,
Phuwanai Thummavet
