Hi Andrei, For my project, I need released maven dependencies to point at, so I can't move up to trunk yet.
If I'm understanding things correctly, the default behavior of in the trunk code, is that if I only want the latest version, then, I just do nothing special, and it only keeps the latest version. Is that also true in the 1.4.197 release? I've been calling the setVersionsToKeep(0), as despite the documentation, it seems to be used for some things in the file store.... but that's just from a cursory look at the code. That's really all I want, is the disk-backed ConcurrentHashMap behavior, not the version store. I tried not calling compactMoveChunks(), but in my use pattern, it leaves the DB way too big. It seems to be ok, if I only call it when there aren't any other threads hitting the data store. If I call it when other things are happening, it breaks the MVStore pretty reliably, per the other thread I started. So there are obviously some multi-threading issues in the 1.4.197 line. I could do some testing at some point with your trunk code, if you want me to see if the multithread issues are fixed in trunk. Thanks, Dan On Monday, July 2, 2018 at 1:18:39 PM UTC-5, Andrei Tokar wrote: > > Hi Dan, with respect to version management in MVStore, there are > significant differences between 1.4.197 release and trunk, that’s why I > would recommend to check out latest code. > Number of versions kept in a file-based store is determined by usage. In > absense of registerVersionUsage() / deregisterVersionUsage() calls, only > latest version will be kept. This is only safe to do in a single-threaded > scenario without auto-commit. Once you have more than one thread (including > background auto-commit one), “current” version may be not what you think it > is, and your operation, i.e. map iteration via cursor, may fail due to the > fact that version it was iterating on, has been removed. That is why > interest in specific version (and coincidentally all subsequent ones) > should be expressed via registerVersionUsage(). > In addition, time-based policy may be used with setRetentionTime(), but it > never be 100% reliable, and mainly exists for usage simplicity and backward > compatibility. > You may call compactMoveChunks() if you want, but that not strictly > necessary, because space occupied by unused versions will be eventually > re-used. -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
