Use a context data library, cls-hooked to fix a context issue reported in #105.
Previously, convector had problems with concurrent transaction, because it was setting a global variable BaseStorage.current on each chaincode @Invoke. This variable contains a reference to the Fabric STUB object, where operations (reads and writes to the ledger) get written for each transaction. So when a second @Invoke is received, the STUB gets overwritten, and all the operations of the first transaction still pending to run (because asynchronicity) end up being registered in the incorrect STUB. This causes all sorts of wrong behaviors, like trying to write in a transaction STUB that has already finished, or simply putting the reads and writes in different blocks, which is not accurate at all.
Types of changes
[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
Proposed changes
Use a context data library, cls-hooked to fix a context issue reported in #105.
Previously, convector had problems with concurrent transaction, because it was setting a global variable BaseStorage.current on each chaincode
@Invoke. This variable contains a reference to the Fabric STUB object, where operations (reads and writes to the ledger) get written for each transaction. So when a second@Invokeis received, the STUB gets overwritten, and all the operations of the first transaction still pending to run (because asynchronicity) end up being registered in the incorrect STUB. This causes all sorts of wrong behaviors, like trying to write in a transaction STUB that has already finished, or simply putting the reads and writes in different blocks, which is not accurate at all.Types of changes
Checklist