Ioana Danes wrote [10/03/2006 08:31 PM]:
I think the first set of inserts in table1 are correct
because the locks are not acquired at the table level,
they are acquired at the row level on two different
records as ROW EXCLUSIVE LOCK. So, they should not
lock each other.
You are right about the correctness of the transaction. There is no
question about this. Moreover, IF table-level locking was happening,
although not strictly required, you would not have any deadlock.
Is it a hard requirement for you that row-level locking is used ?
If not, making this work can be as simple as turning on table level
locking in your vdb.xml file using
<WaitForCompletion enforceTableLocking="true"/>
T3 (insert into table1) should grab the row lock on
table1 on a new record (not as T2 or T3) and then
commit. But what is happening is T3 it waits for
something and then we get the deadlock because T2
waits for T3 and viceversa...
The "something" is T2.
Sequoia does fancy things in such cases. T2 is blocked in the db, but
holds the (sequoia pseudo) lock on table 1, which is required by T3.
The exact details would require digging into how the conflicting and
non-conflicting queues work.
A+O.
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
