Hi, sorry for late reply, but perhaps you find this interesting.
MapDB is db engine similar to MVStore. On its own it does not support transactions or snapshots, but it has separate wrapper which provides those features (search TxMaker and TxEngine). I think it could be perhaps used to provide snapshots and serializable transactions for MVStore as well. Jan On Monday, April 21, 2014 02:28:02 Kieron Wilkinson wrote: Hi Thomas, I've been thinking about this the last few days, writing various unit tests to learn how MVStore works and I think that, in retrospect, hardcore serialisation isolation is really quite a difficult thing to achieve in a generic way. This article was quite useful to me to think about the difference, though no doubt you are more familiar with these things than I am: http://blogs.msdn.com/b/craigfr/archive/2007/05/16/serializable-vs-snapshot-isolation-level.aspx So, I wonder whether it actually makes more sense to concentrate on implementing snapshot isolation instead, particularly as the concept seems to fit in well with what MVStore already does. I'll be honest and say that I don't think I would be able to dedicate the time required to get serialisation isolation correct and working well. I also think it could be even more difficult to achieve in a general key-value store where the queries could be basically anything (what would you lock against when somebody uses some value-based predicate?). But maybe I'm not thinking about the problem clearly enough... I do need some sort of serialisation isolation, but I think actually I can do that much more easily on top, as I only need to do enough in that case to satisfy my particular needs, which are fairly well defined at an application level. I also think that as a starting point, I can do a rather naive implementation of snapshot isolation, where you don't track what is inserted/deleted, just that something has, and you fail all other concurrent transactions that don't "win". That does mean the concurrency is massively limited when there are many inserts/deletes, and user code will get a lots of rollbacks, but I thought might be a good starting point to get the basics in there. Please let me know what you think. Thanks, Kieron Seems like I have quite a lot of learning to do though, so might take a little while. I assume by what you said that I can change the public API in incompatible ways? If I start with what you suggested, and I very well might, that would already potentially break code if you wanted to merge any changes back in. Anyway I'll let you know if I manage to put together anything interesting. Thanks, Kieron Hi, > I want to be able to block or force a rollback rather than seeing the old > value It's hard to say what is the best way to implement it. It would be nice if the TransactionStore could be extended. The first thing to do is probably create separate top-level class files, and then possible split TransactionMap into 3 classes: TransactionMapBase, TransactionMapReadCommitted, TransactionMapSerializable. Or something like that. A part of the logic is already there: TransactionMap.trySet, which returns true if the entry could be updated. For the database, I ended up implementing some of the logic in MVSecondaryIndex.add, as there are some complications with what exactly is a duplicate entry. > a serializable-style of isolation requires a lock per entry It's possible to implement it that way, but I wouldn't, as it doesn't scale (it would need too much memory and probably get too slow). Instead, I would use just one, or a fixed number of lock objects. The risk is that the thread that is waiting for one particular row is woken up even if the different row is unlocked, so the thread would have to wait again. But that way you don't need much memory. But it depends on the use case. As for the license: if you write your own class (without copying H2 source code), then you can use your own license and don't have to publish the code (but if you want, you can, of course). If you modify an existing H2 class, then you would have to provide or publish those changes (just the changes, not the source code of the rest of your application). Regards, Thomas On Fri, Apr 18, 2014 at 1:28 PM, Kieron Wilkinson <[email protected]> wrote: http://> h2database.com/html/mvstore.html#transactions[1] >Yes, that's what it's doing. But not there are some differences between "serializable" (what you want) and "read committed" (what the >TransactionStore supports right now) - for details, see http://www.postgresql.org/docs/9.3/static/transaction-iso.html[2] and http://en.wikipedia.org/wiki/Isolation_(database_systems)[3] -- 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 http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
