I would like to thank Andrew Sayer for the correct solution. A select statement without a for update clause can not set a transaction lock. The transaction lock must therefore come from another statement of the same session.
As long as no commit has taken place, the lock is upright. We would therefore have to go back in time using active session history to determine where the transaction lock originated.
Basically, it is a good idea to speed up the long-running Select statement. This allows the transcation lock to be held for a shorter period of time, since the commit point can be reached more quickly.
Recently I had to research a “enq: TM contention” wait event. I queried active session history (ASH) an found blocking session’s id.
I queried ASH again and found what the blocking session was doing right at the time when the other session was waiting on the “enq: TM contention” lock. At this time there was a long running select statement active in the blocking session.
How is that possible? Can a select create a lock? What must have happened ? Would it actually help to tune the select?
For a further hint you might wat to read Arup Nanda’s blog on transaction locks.
enq: TX row lock contention and enq:TM contention