There is one SortKeyCache instance for reading/writing contract state cache.
As ppe pointed out this means that the rollback batch is shared among all contract cache.
In case of a very unfortunate events order this may cause some incorrect rollback/commit behaviour??
Since now we do not perform any rollbacks on the state cache this seems not be a problem, at least for now...
Warp evolves very fast and it is very important to keep that issue mind and maybe change the rollback implementation to a map
Map<tx_id, rollbackBatch>
Related to
warp-contracts/warp-contracts-lmdb#24 (comment)
There is one SortKeyCache instance for reading/writing contract state cache.
As ppe pointed out this means that the rollback batch is shared among all contract cache.
In case of a very unfortunate events order this may cause some incorrect rollback/commit behaviour??
Since now we do not perform any rollbacks on the state cache this seems not be a problem, at least for now...
Warp evolves very fast and it is very important to keep that issue mind and maybe change the rollback implementation to a map
Map<tx_id, rollbackBatch>
Related to
warp-contracts/warp-contracts-lmdb#24 (comment)