Re: is the MVStore production ready

[Thomas Mueller]

Hi,

I don't expect any big changes, but I still consider it experimental, because the API might change, and because it is not fully tested (specially multi-threading). But depending on your use case it might already be "good enough", specially if you have your own test cases to ensure the features you use are working as expected.

Regards,

Thomas

On Wed, May 8, 2013 at 11:25 AM, Thorsten Marx <thm...@gmx.net> wrote:

Hi,

I'm looking for a java embedded key-value store with support for versioning. 

I've found the MVStore implementation and it seems to be exactly what I'm looking for. 

My question is, is it usable for production in the current version?

Kind regards

Thorsten

--
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 h2-database...@googlegroups.com.
To post to this group, send email to h2-da...@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Thorsten Marx]

Thanks for the reply. 

Most of the time I only use put and get, I think these methods will be stable and I don't need to change my code very often.

I will try it.

[Thomas Mueller]

Hi,

By the way, currently you need to call "commit" from time to time (not too often if possible, for best performance). This is currently needed, but I think in future versions there will be "auto-commit" from time to time by default (a feature that can be disabled). This will still allow you to commit manually, but it will no longer be needed.

Regards,

Thomas

[Thorsten Marx]

Hi,

good to know.

Can you give me some hints for using compact. I have a simple test, where 100000 objects are added to a MVMap. When I call clear on the map all entries are removed but the filesize is still the same. When i start the test again, the filesize increases, even if I call compact. shouldn't compact reduce the filesize.

regards,

Thorsten

[Thomas Mueller]

Hi,

Yes, it's quite hard to get the MVStore to shrink the file size. Disk space is re-used, but in this case the file should shrink a lot more quickly I think. Well, it shouldn't shrink immediately, to ensure changes are not lost if there is a power failure (this is quite a hard problem to solve), but it should shrink eventually.

Thanks to your description, I have a test case now that should help me fix this issue. I did have a few test cases, and disk space is re-used, but there still seem to be a few bugs.

Thanks a lot!

Regards,

Thomas

[Igor castang]

Also Thorsten

you may want to use the last svn version (in case you were not already) I ran into this when testing the MVStore and it seemed similar to what you are trying

https://groups.google.com/forum/?fromgroups#!searchin/h2-database/igor$20castang/h2-database/MsH6LWaP25Y/4Ms-KliXb6IJ

this got fixed in SVN (but not yet released as there hasn't been a new H2 version since)

regards

[Thomas Mueller]

Hi,

By the way, about compacting a store, I think I understand now the reason why the file does not shrink.

By default, the MVStore keeps old data for up to 45 seconds. This is to avoid having to call fsync, see also http://stackoverflow.com/questions/13650134/after-how-many-seconds-are-file-system-write-buffers-typically-flushed

I guess you didn't wait 45 seconds :-) I don't blame you, as you couldn't possibly have known, and I forgot about that as well.

I understand it might be a bit strange to wait for such a long time before overwriting old data or truncating the file. But the alternative is to call fsync, which doesn't always work reliably. And is very slow if it does work.

Maybe fsync could be called, multiple times to just make sure, when closing the store. This is something to consider.

Regards,

Thomas