Blocking Locks - What Was Likely Going On?

Question

I had a blocking lock yesterday that showed up in OEM under Cluster Database --> Cluster Database Locks. The blocking lock was a row exclusive (RX) table lock that was blocking 175 other sessions that were listed under the blocking lock as having requested row share (RS) locks. It was an hour before I found out about this problem.
Two questions:
1.] The "Oracle Database Concepts 10gR2" book, Table 13-13, states that a row exclusive (RX) table lock can be obtained as a result of INSERT, UPDATE or DELETE DML and that in RX mode share lock modes are not permitted (which is why I had 175 blocked sessions). Does this mean that a user must have been doing a long running (1 hour plus) INSERT, UPDATE or DELETE or is there another more likely cause that I'm not aware of?
2.] The only ways I know of to request a row share lock (of which 175 were blocked due to the RX lock) is by using:
LOCK_TABLE <table name> IN SHARE MODE;
LOCK_TABLE <table name> IN SHARE EXCLUSIVE MODE;
LOCK_TABLE <table name> IN EXCLUSIVE MODE;
I can't imagine a user doing any of these commands so is there another more likely reason that 175 row share (RX) locks were being requested (and blocked)?
Thanks for any insight you can offer. I ended up killing the session that held the RX lock and that resolved the problem but I'd like to better understand what was happening.

Answer 1

1.] The "Oracle Database Concepts 10gR2" book, Table
13-13, states that a row exclusive (RX) table lock
can be obtained as a result of INSERT, UPDATE or
DELETE DML and that in RX mode share lock modes are
not permittedThat table shows that RS (mode 2) is permitted while RX lock is held.
Did you mean to say that sessions were waiting on a S mode (4) lock?
This could indicate that update/delete was attempted on a parent table and that dependend table was lacking an index on fk column. (may answer your q.2)