Ioana Danes wrote [10/12/2006 01:04 PM]:
Hello Everyone,
Do you have any news regarding this issue?
Hi Ioana,
After some talk with the Architect, it looks like we are not going to
fix the code. The main point for not doing a fix in the code is that we
have no means of telling that the first request in the conflicting queue
is blocked in the db, thus no means of doing a safe cluster-wide
'priority inversion'.
The current status for transactions that rely on row-level locking is as
we said last week: not supported and may lead to unexpected aborts (due
to the deadlock detection mechanism).
Note that the deadlock detection mechanism, as annoying as it may seem,
is kind of 'safe' in the sense that it consistently aborts one
transaction cluster-wide thus preserving data integrity across backends.
There are two alternatives to workaround this 'feature' for transactions
that are known to be logically correct and deadlock-free:
1/ enforce table level locking in order to avoid the deadlock detection
glitch. This option incurs a performance drop as you demonstrated.
2/ use semantic information to disable table level locking for those
specific queries that should not have taken then the table lock in the
first place.
You may choose to try option 2 and see if it works for your case by
specifying semantic info for request "Insert Into Table1". You'll want
to use cvs:head for this, or wait for 3.0-beta to be released.
Hope you'll give the semantic info a try. Keep us posted.
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
