Hi, > H2 would still block the reader > in the second transaction is what I am hearing. Could you please > confirm my understanding is correct?
Yes. > 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. Yes. Even without "update my_table set ... where id = 1". However, if you replace "select ... from my_table where id = 1 for update" with "update my_table set id = id where id = 1" then it should be fine (I didn't test it yet however). > 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 Yes. The problem is that the current implementation in H2, the SELECT FOR UPDATE doesn't do what it's supposed to do for MVCC: it locks the table in exclusive mode. This is a known problem since quite a long time, but I didn't have time to implement it yet. It was just not important enough so far. Now, one of the top priorities, and it should be relatively easy to implement (internally replacing the SELECT with a dummy UPDATE). Maybe it will be implemented in the next release (in about two weeks), but not sure yet. Regards, Thomas -- 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.
