You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using current master, the attached procedure will end with 'MVStoreExeception: Double mark' after 2nd run, after that the store is unopenable (with the same error). This won't happen if 'store.compactFile(200);' is commented out.
@wburzyns, Thanks for posting a test case. I am able to reproduce the problem.
This looks like a bug in MVStore.rollbackTo(). This method is relatively lightly tested, since it is not used by H2. It is not thread-safe by design, and IMHO should be deprecated/removed. I wonder what is your use case for it? Can't TransactionStore be used here instead, if you need some sort of a roll back functionality?
Anyway, I've created a PR, which hopefully will fix your issue.
At the moment I've no specific use for this method. I was just playing around the MVStore.
BTW Could you advise how many versions are retained in case of a file store? For in-memory stores there is a method MVStore.setVersionsToKeep (5 by default) but there is no similar method for file stores.
MVStore version will be retained if it falls within explicit number of versions to keep (default 5 for in-memory and 0 otherwise) or if it is still in use by any operation in progress. Operation demarcation is done by MVStore.registerVersionUsage()/deregisterVersionUsage(). There is also indirect time-based barrier, which prevents otherwise unused chunks to be garbage collected (their space re-used), which is governed by MVStore.setRetentionTime() (default 45 sec).
Therefore, if application uses mvstore with filestore with zero retention time, and is it's not calling de/registerVersionUsage(), only current version (no historical versions at all) is retained, and even trivial map iteration can blow up in face of concurrent updates and version advancement.
Activity
wburzyns commentedon Apr 26, 2021
Actually it will happen without explicit compaction, but later (when auto-compaction kicks in).
This issue might be related to issues #2752 and #3031.
andreitokar commentedon Apr 27, 2021
@wburzyns, Thanks for posting a test case. I am able to reproduce the problem.
This looks like a bug in MVStore.rollbackTo(). This method is relatively lightly tested, since it is not used by H2. It is not thread-safe by design, and IMHO should be deprecated/removed. I wonder what is your use case for it? Can't TransactionStore be used here instead, if you need some sort of a roll back functionality?
Anyway, I've created a PR, which hopefully will fix your issue.
wburzyns commentedon Apr 27, 2021
At the moment I've no specific use for this method. I was just playing around the MVStore.
BTW Could you advise how many versions are retained in case of a file store? For in-memory stores there is a method MVStore.setVersionsToKeep (5 by default) but there is no similar method for file stores.
andreitokar commentedon Apr 28, 2021
MVStore version will be retained if it falls within explicit number of versions to keep (default 5 for in-memory and 0 otherwise) or if it is still in use by any operation in progress. Operation demarcation is done by MVStore.registerVersionUsage()/deregisterVersionUsage(). There is also indirect time-based barrier, which prevents otherwise unused chunks to be garbage collected (their space re-used), which is governed by MVStore.setRetentionTime() (default 45 sec).
Therefore, if application uses mvstore with filestore with zero retention time, and is it's not calling de/registerVersionUsage(), only current version (no historical versions at all) is retained, and even trivial map iteration can blow up in face of concurrent updates and version advancement.