Ioana Danes wrote [09/29/2006 04:36 PM]:
> Hi all,
>
Hi Ioana,
> Here are the details on how this issue occurs:
>
> There are 2 clients calling the same transaction block
> in the same time:
>
> BEGIN
> Insert Into Table1
> Update Table2
> Insert Into Table 1
> COMMIT
Ok, thanks.
One more question: do you have special constraints on your tables, e.g.
foreign keys ?
> Request Log:
> ---------------
> 11:44:04,908 abrazo B 2
> 11:44:04,913 abrazo W 6 2 insert into table1 values
> (10)/
> 11:44:15,917 abrazo B 3
> 11:44:15,924 abrazo W 7 3 insert into table1 values
> (20)/
> 11:44:16,841 abrazo W 8 3 update table2 set field1 = 1
> where field1 = 1/
> 11:44:23,289 abrazo W 9 2 update table2 set field1 = 1
> where field1 = 1/
> 11:44:26,249 abrazo W 10 3 insert into table1 values
> (22)/
> 11:44:55,499 abrazo R 2
> 2006-09-29 11:47:46,133 DEBUG
> controller.RequestManager.abrazo Commit transaction 3
> 11:47:46,132 abrazo C 3
So we have 2 transactions T2 and T3.
T2 goes first, and grabs (should grab) the write lock on table1.
This should block T3 when it tries to do "insert into table1".
But apparently does not.
This is strange and un-expected (to me at least).
> My expectations are that this scenario should lead us to any deadlock
Same thing here.
My expectations are that T2, since it grabs the lock on table1 first,
should go straight to the end and commit, and this should then let T3 go
and finish.
What is this read by T2 (11:44:55,499 abrazo R 2) ?
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
