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.

Reply via email to