| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: deadlock detection
When transaction B attempts to lock the row, it sees the lock byte on the row is set, and checks the ITL in the block to discover all it can about the transaction in that ITL position. (e.g. has it committed, leaving the block to be cleaned; is it still active).
If the holding transaction is still active, transaction B queues on the transaction table slot (the entry in the segment header block) waiting for it to go from active to free. It doesn't check the row again, it waits for a commit, or a full rollback. (In general a rollback to savepoint won't help, but there are a couple of special cases).
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
April 2004 Iceland http://www.index.is/oracleday.php June 2004 UK - Optimising Oracle Seminar
How does oracle detect deadlocks? Here is my best guess. Oracle's lock
manager tracks locks at the object level, but not at the row level.
transaction A locks row 1 in table A
transaction B locks row 1 in table B
Transaction A attempts to lock row 1 in table B, but is forced to wait. Transaction B attempts to lock row 1 in table A, but is forced to wait.
The oracle lock manager notes that this at the object level. So it is possible that this is a deadlock. The lock manager then checks the transaction table for the row that is locked in each table and from that can determine whether this is a deadlock condition.
Am I correct?
 |
 |