Came out a little ugly; let me repost the clean up... To be clear this is the same row I am talking about. So even in that scenario, with this MVCC case fixed, H2 would still block the reader in the second transaction is what I am hearing. Could you please confirm my understanding is correct?
So basically on the first connection we: 1) start a transaction 2) select ... from my_table where id = 1 for update 3) update my_table set ... where id = 1 (the transaction is still active) Then on a second connection we: 1) start a transaction 2) select ... from my_table where id = 1 Step (2) on the second connection fails with the timeout. Again, I just want to confirm that this is expected behavior as it is different from most of the MVCC impls of which I am aware where the writers are given a special workspace until the changes are merged at end of transaction specifically to allow readers to proceed (depending on isolation), Thanks. -- You received this message because you are subscribed to the Google Groups "H2 Database" group. 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.
