Hi, > About concurrency: it is possible to extend the MVMap to support fully > concurrent operations. For example the R-tree implementation is an > extension of the MVMap. The map implementation used is pluggable. According > to my tests, for in-memory operations, the current MVMap implementation is > about as fast as a TreeMap, which is not synchronized and does not allow > concurrent writes. I guess a concurrent MVMap will be slower and more > complex, but let's see. >
It can be slower on sinlgle thread but allow better throughput in multicore environment in multiple threads. > There are multiple ways to support fully concurrent operations, for > example synchronize on each page, or use a read-only root node. However I > wonder if it's really such a common use case to update a map concurrently, > or concurrently write to and read from the same version of a map. What > exactly is your use case? How do you make sure the threads don't overwrite > each others changes (for concurrent writes)? > It is very common case. Just imagin two users updating their data in some table concurrently. Updates are independent on different unique keys, so why one have to wait another? Of cource if it is possible that one thread can incorrectly override changes from another then application have to manage this itself, because it is a part of business logic, storage should not know it. > Don't you need some kind of isolation? For concurrent write to and read > from the head, don't you think it's a problem that reading will not be > isolated? > For real it depends. My use case is not that complex (and I exploit this), I have no multiple operations in one transaction and each operation is just one add, update or delete by primary key, so each update just goes directly to the datastructure. When I need to execute query I take snapshot in table lock operation and remove it in unlock, main datastructure still can be updated while the query runs over the snapshot. Obvoiusly it will be harder to do it in general way, but I dont think too much. Different transaction isolation levels probably will require different approaches but basically it is all about when to take snapshots and row locks and whent to release them. Probably some kind of merge operation will be needed at map level as well. May be the best option would be make the map transactional itself. > NavigableMap: currently it's a java.util.Map, but yes all features of a > NavigableMap will be supported later on. Maybe this could be done in the > form of a wrapper or abstract base class, to keep the core engine small > (similar to java.util.AbstractMap). > Thats good! Sergi -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To view this discussion on the web visit https://groups.google.com/d/msg/h2-database/-/CXJCDbbIB70J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
