Not quite...

MVCC in validation/commit phase checks the chaincode execution readset key version against current state key version to ensure that the execution results are still valid. Therefore if the chaincode did a read then write of the same key in both transactions, it would behave as Adhav mentions (the transaction that gets ordered later would be invalidated, and would need to be resubmitted for endorsement/ordering by the client).

If the chaincode does a write only without first reading the key, this is called a 'blind write'. In the case of a blind write, there is no readset for the MVCC version check, and therefore both transactions will perform a valid write. The end result would be that T1 writes the key state, and then T2 overwrites the key state - last update 'wins'. This is true regardless of whether the transactions were ordered in the same block or in different blocks.

So in most use cases, you'll want the chaincode to read before writing, to ensure colliding transactions don't go undetected.

The ordering service simply orders transactions as they arrive, it makes no attempt to order transactions based on timestamps or any other intelligence. The timestamp that the client adds to the transaction is just for reference, it is not used by ordering service or any other component for that matter.


Dave Enyeart

"Adhav Pavan" ---05/09/2020 01:06:40 PM---Hello Marco, When committing a peer to get block from the orderer, first it validates

From: "Adhav Pavan" <adhavpavan@...>
To: marco.comuzzi@..., hyperledger-fabric <hyperledger-fabric@...>
Date: 05/09/2020 01:06 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric-orderer #fabric-chaincode
Sent by: fabric@...

I have a question regarding the ordering of transactions changing the value of the same variable in the world state:

Lets' assume that the 2 clients C1 and C2 submit two transactions (T1 submitted from C1 and T2 submitted from C2) that modify the value of the same variable "v" (identified by key "k"). Let's also assume, for simplicity, that for both T1 and T2 have an empty read set.

As far as I understand (reading [1]), both transactions will be endorsed by the endorsing peers, because they do not violate the "read your writes" policy.
However, what determines the order in which T1 and T2 will be included in block(s) and, therefore, what determine which will be the value of the variable "v" after both transactions are validated and committed by peers?

(I guess that in case T1 and T2 are submitted by the same client, then the orderer service will follow the timestamp to determine the correct order. The client must in fact timestamp the transactions progressively. I am not sure what happens when such transactions are originated from different clients)

Thank you
Marco

[1]  https://hyperledger-fabric.readthedocs.io/en/release-2.0/readwrite.html

I think most use cases will want the read-write behavior.
Append-only use cases may want the blind write behavior. For example consider an IOT sensor that records a data point hourly. There isn't really a need to detect collisions. Performance would be better if you did blind writes, and in the rare case a sensor sent the same data point twice, having the later transaction overwrite the first would be acceptable.


Dave Enyeart

"Rob Murgai" ---05/11/2020 02:58:09 PM---I am curious, what use case would require a blind-write vs a read-write? S Rob Murgai

From: "Rob Murgai" <murgai@...>
To: marco.comuzzi@...
Cc: fabric@...
Date: 05/11/2020 02:58 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric-orderer #fabric-chaincode
Sent by: fabric@...

S Rob Murgai Program Director - Hyperledger Fabric IBM Blockchain Raleigh-Durham, NC M: 919.342.8432 | LinkedIn: Rob-Murgai