[Neo Store Exception] Add exception to Use after Commit operation to Snapshots and Cache.

[Jim8y]

Description

Store snapshot and datacache are not supposed to be used after they are commited since there will be data inconsistancy and very hard to figure out the exact value. Thus we need to ban any attacmpt of using the snapshot or data cache after they are committed.

Fixes # (issue)

Type of change

• Optimization (the change is only an optimization)
• Style (the change is only a code style for better maintenance or standard purpose)
• Bug fix (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)
• This change requires a documentation update

How Has This Been Tested?

Test Configuration:

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[cschuchardt88]

I don't think this is a good idea. If snapshot isn't disposed You should still be able to use it. I think it does in ApplicationLogs

[Jim8y]

I don't think this is a good idea. If snapshot isn't disposed You should still be able to use it. I think it does in ApplicationLogs

you can not use it anymore, cause the value was there before the commit, but will be gone after the commit. you will get unexpected result. if applicationengine or something is using a committed cache, we should fix it. and if you use your experience with snapshot on neo, you should rethink it, cause its different here.

[Jim8y]

the problem is, you had newest state, but after you commit it, you lose the latest state but fallback to the point when the snapshot is created, making the snapshot unable to process with correct data anymore. thus you should never use a clmmitted snapahot or datacache.

[cschuchardt88]

the problem is, you had newest state, but after you commit it, you lose the latest state but fallback to the point when the snapshot is created, making the snapshot unable to process with correct data anymore. thus you should never use a clmmitted snapahot or datacache.

Thats not true. Because the Read methods get results from the db. So after you commit data, data isn't lost. If you were to read data snapshot, it would come from the db not the snapshot anyways. So if you put new data in and commit it, snapshot will be committed to db. Data isn't visible to snapshot until you commit.

Hints my comment for: #3399 (comment)

[shargon]

this flag must be changed to false when write or delete, isn't it?

[Jim8y]

it would come from the db not the snapshot anyways

Please check my pr on memorystore UTs.

[AnnaShaleva]

Please, see the #3404 (comment). How this do-not-use-after-commit rule is going to work with blocks processing? I'm probably missing something.

[cschuchardt88]

Why can't you on commit. Refresh the snapshot? Would be much simpler.

[Jim8y]

the problem is, you had newest state, but after you commit it, you lose the latest state but fallback to the point when the snapshot is created, making the snapshot unable to process with correct data anymore. thus you should never use a clmmitted snapahot or datacache.

Thats not true. Because the Read methods get results from the db. So after you commit data, data isn't lost. If you were to read data snapshot, it would come from the db not the snapshot anyways. So if you put new data in and commit it, snapshot will be committed to db. Data isn't visible to snapshot until you commit.

Hints my comment for: #3399 (comment)

read my test. You can not assume where the data comes from, when you read the data, its from the snapshot of the db, not the db latest state.