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 
> <[email protected]<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 [email protected] <javascript:>.
>> To post to this group, send email to [email protected]<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 
> <[email protected]<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 [email protected] <javascript:>.
>> To post to this group, send email to [email protected]<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 [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.

Reply via email to