Confessions of an Oracle Database Junkie - Arup Nanda
The opinions expressed here are mine and mine alone. They may not necessarily reflect that of my employers and customers - both past or present. The comments left by the reviewers are theirs alone and may not reflect my opinion whether implied or not. None of the advice is warranted to be free of errors and ommision. Please use at your own risk and after thorough testing in your environment.

Transaction 3 now wants to update either row 1 or row 2. It will hang of course. But will it trigger the creation of a new ITL slot?

I also decided to expand the questions to cover one more scenario. Transaction 4 wants to update row 1 and row 4 in the same statement. Row 4 is not locked; but row 1 is. So will transaction 4 be allowed to lock row 4, even though the statement itself will hang? Will it trigger the creation of another ITL?

Examination

Let's examine these question via a case study. To demonstrate, let me create a table with three rows:

This will hang. The reason is obvious. The transaction is trying to get a lock on rows 2 and 3. Since row 2 is already locked by transaction 1, it can't be locked. However, what about row 3? It should have been able to be locked. Was it locked? Let's make a simple check by updating only row 3 from another session, which was attempted to be locked by transaction 2.

There are only two transactions that have placed locks. If you combine the XIDUSN, XIDSLOT and XIDSQN, separated by periods, you will get the transaction ID shown earlier. The transaction that is hanging has not placed a lock on the row it could have put a lock on. That is consistent with the concept of statements inside transactions - either all rows will be updated or none - not in piecemeal. If one of the rows can't be locked, none of the rows will be.

What about ITL slots. Let's see them by doing block dumps. First , we need to know the block number these rows are in:

Note how the output matches the entry under the column marked "Xid" in the Itl output. you saw the same transaction IDs in the same Itl. There are just two ITL slots and each slot points to a transaction that has placed the lock. The transaction that has not placed the lock is not given an ITL slot; there is no no need for it.

Lock Change

Now suppose Transactios 1 and 3 ended by either commit or rollback. Transaction 2, which was hanging until now, will be free to put the locks. Let's see the ITL slots: