Heavy row lock contention

Question

Guys,
I really appreciate your views on this.. Please can some one who have worked on RAC and have an understanding how RAC works, guide me.
We currently are running a loadtest on one of the new RAC system and we are seeing excessive row lock contention for one table. The table basically has very few rows, say about 6-8 and pretty much every user uses this table to lock rows before fetching some data from other tables. When have a heavy load, we see very high wait on this table and enq TX : Row lock contention.
What is the best way to avoid this ? Is there anyway, we can modify the design of the application and ensure locking.. The typical query that locks the rows in the table looks like this
SELECT WL0.CLUB_NAME, WL0.SCHEDULE_ID FROM VF_BINGO_NEXT_CLUB_DRAW WL0 WHERE ( WL0.CLUB_NAME = :1 ) FOR UPDATE As said, they table has only 6-8 rows, so query plan etc doesn't apply. Please can someone who have extensive application knowledge guide me thru ?
Many thanks in advance.
G

Answer 1

> But is there a way to alliviate the concurrency issue, if there is a genuine
requirement to hold lock on a table. What other options do we have other
than locking ?
The purpose of a lock is to ensure data consistency - only 1 process can change that row. So what I find puzzling is why so many app sessions want to change that single row. What data does that row hold that requires continual change? Just what is the purpose of this data if it is consistently and continually changing? What business requirement does it attempt to solve?
To be honest, this sounds like a major design problem to me.
Like the surrogate key generator approach I mentioned. You create a PK_SEQUENCE table with columns (tablename, pk_value). Any insert against a table requires a lock on PK_SEQUENCE for the table being inserted into - a read of the PK_VALUE, incrementing it by one and then updating that row with the latest sequence. This way each INSERT gets a "nice sequential number" to use as surrogate key for new rows.
Even when this is done as an autonomous transaction, it introduces a very expensive resource - why? Because only one session at a time can be serviced by that resource.
If there are a lot of INSERTs into a table, this approach will quickly become a severe bottleneck as every single insert requires a new surrogate key value and a lock on that PK_SEQUENCE table to obtain that value.
This problem is solved by allowing/enabling such a resource to serve multiple sessions concurrently. Which is for example what Oracle Sequence objects do within this example I've described.
The bottom line is that the design you describe introduced a bottleneck by create an expensive and serialised resource that can only serve a single session at a time.
You need to re-look at the business requirement - and find another way to solve it than to introduce this type of serialised resource and contention.