Hi Thomas, > It sounds like you want something like the TransactionStore utility (org.h2.mvstore.db.TransactionStore), but for serializable transactions: http://> h2database.com/html/mvstore.html#transactions<http://h2database.com/html/mvstore.html#transactions>
Yes, exactly. TransactionStore is what I have been playing around with and written my tests against. I've read that page a couple of times, very interesting stuff. >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 and http://en.wikipedia.org/wiki/Isolation_(database_systems) Thanks for the links. I have read those pages too, plus loads of other trying to gain enough knowledge to write my own, though it's still all a bit new to me, so I'm pretty sure it's not all gone in yet. :) I definitely need to read the Postgres one again. My unit tests against MVStore do indeed indicate the read-committed functionality works as I understood it. One transaction can "see" other writes as soon as their transactions are committed. And indeed, if that happens, I want to be able to block or force a rollback rather than seeing the old value (which is useful for some other stuff I want to do, but not this particular use case). > Please have a look at the docs, and then let's discuss whether you want to extend the current mechanism or write your own. I'm also interested > in having serializable transaction isolation for H2 as an option, but would like to keep the current mechanism as the default. Yes, that makes sense. I was hoping I could build on top of what is there, but I wasn't sure how configurable it was. I also gather that a serializable-style of isolation requires a lock per entry, which I guess would add quite a bit of overhead, and we would need to be careful about deadlock, as they would be taken, I suppose, in whatever the reads are happening. Do you think I can build on top, or you do you think this sort of change is quite fundermental to how the current TransactionStore works? Thanks, Kieron On Friday, 18 April 2014 09:43:14 UTC, Thomas Mueller wrote: > > Hi, > > It sounds like you want something like the TransactionStore utility > (org.h2.mvstore.db.TransactionStore), but for serializable transactions: > http://h2database.com/html/mvstore.html#transactions > > > I would like to get reads of values to either block until the other > writing-transactions finish, or fail so I can re-execute at a later time. > > 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 and > http://en.wikipedia.org/wiki/Isolation_(database_systems) > > Please have a look at the docs, and then let's discuss whether you want to > extend the current mechanism or write your own. I'm also interested in > having serializable transaction isolation for H2 as an option, but would > like to keep the current mechanism as the default. > > Regards, > Thomas > > > > > > > On Fri, Apr 18, 2014 at 10:39 AM, Kieron Wilkinson > <kieron.w...@gmail.com<javascript:> > > wrote: > >> Hi, >> >> I've been looking for an in-memory key-value database. I couldn't find >> anything (that was missing deal breaker features), so I spent several days >> writing my own one, and then realised how hard it was ;). I did some more >> investigation and thankfully found MVStore. >> >> Anyway, I think it provides pretty much everything I need (which is >> fantastic!). One of the things it doesn't do is something similar to >> serializable transaction isolation. I would like to get reads of values to >> either block until the other writing-transactions finish, or fail so I can >> re-execute at a later time. >> >> So, I was wondering, if I wanted to plug this functionality in, whether >> you guys had any hints on the best way to go about that? I was assuming >> that since H2 itself supports serializable isolation, that this can be >> easily implemented on top? Maybe, if you think it's useful, I can even make >> my code generic enough that it is useful for others, as an optional >> component for MVStore. >> >> I also would like to customise the support for 2-phase commit. I would >> like to apply my application's optimistic locking checks in the prepare >> phase (which I can do externally), but after taking write locks in the >> prepare phase to enforce the contract of these checks on commit. Does that >> seem possible? >> >> Anyway, thanks very much for your work. >> >> Kieron Wilkinson >> >> -- >> 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 <javascript:>. >> To post to this group, send email to h2-da...@googlegroups.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/h2-database. >> For more options, visit https://groups.google.com/d/optout. >> > > On Friday, 18 April 2014 09:43:14 UTC, Thomas Mueller wrote: > > Hi, > > It sounds like you want something like the TransactionStore utility > (org.h2.mvstore.db.TransactionStore), but for serializable transactions: > http://h2database.com/html/mvstore.html#transactions > > > I would like to get reads of values to either block until the other > writing-transactions finish, or fail so I can re-execute at a later time. > > 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 and > http://en.wikipedia.org/wiki/Isolation_(database_systems) > > Please have a look at the docs, and then let's discuss whether you want to > extend the current mechanism or write your own. I'm also interested in > having serializable transaction isolation for H2 as an option, but would > like to keep the current mechanism as the default. > > Regards, > Thomas > > > > > > > On Fri, Apr 18, 2014 at 10:39 AM, Kieron Wilkinson > <kieron.w...@gmail.com<javascript:> > > wrote: > >> Hi, >> >> I've been looking for an in-memory key-value database. I couldn't find >> anything (that was missing deal breaker features), so I spent several days >> writing my own one, and then realised how hard it was ;). I did some more >> investigation and thankfully found MVStore. >> >> Anyway, I think it provides pretty much everything I need (which is >> fantastic!). One of the things it doesn't do is something similar to >> serializable transaction isolation. I would like to get reads of values to >> either block until the other writing-transactions finish, or fail so I can >> re-execute at a later time. >> >> So, I was wondering, if I wanted to plug this functionality in, whether >> you guys had any hints on the best way to go about that? I was assuming >> that since H2 itself supports serializable isolation, that this can be >> easily implemented on top? Maybe, if you think it's useful, I can even make >> my code generic enough that it is useful for others, as an optional >> component for MVStore. >> >> I also would like to customise the support for 2-phase commit. I would >> like to apply my application's optimistic locking checks in the prepare >> phase (which I can do externally), but after taking write locks in the >> prepare phase to enforce the contract of these checks on commit. Does that >> seem possible? >> >> Anyway, thanks very much for your work. >> >> Kieron Wilkinson >> >> -- >> 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 <javascript:>. >> To post to this group, send email to h2-da...@googlegroups.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/h2-database. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.