Does MVStore make blocking IO calls?

60 views
Skip to first unread message

Vincent Ngan

unread,
Jul 24, 2020, 10:48:57 AM7/24/20
to H2 Database
Hi,

I like MVStore very much. It is just a great library for implementing embedded key/value database solutions. I have also been using Kotlin for development. One of the great things about Kotlin is its asynchronous coroutines feature. In order to use Kotlin coroutines effectively, it is important that your code does not do any synchronous blocking IO. I am not sure whether I can use MVStore library safely in coroutines assuming that it does not do synchronous blocking IO. It is obvious that when MVStore is configured to use FileStore or OffHeapStore, some kind of system IO will be incurred. But, what if I just use the in-memory part of MVStore without configuring it with any FileStore? Does the pure in-memory part of MVStore make any blocking system calls?

Best regards,
VN

Andrei Tokar

unread,
Jul 25, 2020, 4:33:26 PM7/25/20
to H2 Database
The short answer - it depends.

Majority of MVStore operations for in-memory case are non-blocking, especially if you use it in a low-contention scenario, but if you have many threads competing for doing some map updates, threads may yield, sleep or even go for lock acquisition after some failed non-blocking attempts. Your read operations are guaranteed to go non-blocking in any case.

Just curious, what you are trying to achieve with pure in-memory MVStore (without transactional functionality), that can not be done with stock JDK SortedMap implementations like TreeMap or ConcurrentSkipListMap?

Vincent Ngan

unread,
Aug 1, 2020, 12:37:34 AM8/1/20
to h2-da...@googlegroups.com
Hi Andrei,

Thank you for your answer. I have actually created an implementation for my in-memory solution using stock JDK TreeMap, but I need better transaction support with reliable commit and rollback, and multi-versioning mechanism. I can achieve persistence for this in-memory database not by using FileStore, but by streaming transaction changes to Kafka. This allows the in-memory database to be recovered on a different machine. It also allows me to implement real-time read-only replication of my in-memory database.

Best regards,
VN

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/h2-database/6073ba22-0d19-42ad-8382-57c924f07af8o%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages