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? On Friday, July 24, 2020 at 10:48:57 AM UTC-4, Vincent Ngan wrote: > > 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 > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/h2-database/6073ba22-0d19-42ad-8382-57c924f07af8o%40googlegroups.com.
