Z/os db2 (type 2) transaction isolation from rr to cs, general questions

Question

Let me preface this by saying I'm pretty uninformed when it comes to database transaction isolation and what it really means to my application. I've done some homework on the differences between the read committed (cs) and repeatable read (rs) but still a little fuzzy.
App stats: Mainframe z/os db2 v8 (type 2 driver), WAS 6.0.x.x The app runs with about 80000 concurrent users (using about 150-200 JDBC connections in the pool).
I found this which held some good information: http://forum.java.sun.com/thread.jspa?forumID=48&threadID=586570 but it leaves me with some questions still.
Our Mainframe dba is saying he sees a lot of locking (not dead locks, just locks) and it is eating up the MIPS. He told us to set our transaction isolation level to cs to reduce the locking db2 does. But I don't know enough about this to make a good decision. The general consenus I've gotten from various forums (spring, hibernate) is that using CS will cause more problems than it will fix.
The only sql error I see in our logs is due to an insert or update to a FK being invalid. I suppose this could cause some locking problems but would this cause deadlocks?
If anyone can provide some links to explain this, I'd be really appreciative. Or if you have any first hand knowledge -- even better.
Thanks for your time.

Answer 1

I am also not an expert and haven't used DB/2 on z/OS but am using it on OS/400. I think your DBA is confused.
From what I have experienced setting commit control to CS causes more locking than RS. From what I can determine (which has been through trial and error so it may not be totally accurate) CS causes the database to exclusive lock all records in the cursor while RS will use shared locks. I do know from painful experience that if you set all your transactions to CS you will experience frequent update problems due to record locks.  We had to go through and set everything to RS and, once we did, our concurrency problems were nearly eliminated. There are some instances that you have to use *CS, however, such as when a stored procedure returns a cursor, but the compiler will tell you about this.
Another thing that doesn't make sense is locks are typically implemented as data structures in memory and do not require much if any processor time. I don't know the specifics of DB/2 implementation but Oracle uses simple semaphores, so I would assume IBM does, too.
Also, from my experience, there appears to be no way around DB/2 locking. Having come from an Oracle background I find the amount of locking DB/2 does totally frustrating. It's not as bad as SQL Server but can become problematic at times. That is just my $.02 anyway.