concurrent access deadlocks

I am using Work objects (asynch beans) running inside websphere app server 6.0. and hibernate as O/R layer.

There are about 80 Work objects, querying and updating tables in DB2 simultaneously.
I have set the lock percentage parameter to 100% for this database and I am sure there is no concurrent access to the same records by more then one thread because each Work object is assigned a different group of records.

Still I get deadlocks after a the application is running for a while (minutes).

Will appreciate any ideas.

aditi1Asked:
Who is Participating?
 
ocgstylesConnect With a Mentor Commented:
Hi aditi1,

Deadlocks are hard to track in real time, since by the time you try to find out what locks are conflicting, one of the applications' transactions has rolled back.  You can track the number of deadlocks encountered using a snapshot, but to get the detail on the locks, you to use an event monitor.  This will tell you what locks existed at the time of the deadlock as well as the locks granularity (row or table)

What I imagine is happening is...
If one if your applications is requesting row locks, and you exceed the percentage of the lock list you're allowed, a lock escalation will occur and DB2 will try to convert your row locks into a table lock.  If lock escalation is attempted while other row locks exist, that application will sit in lock wait.  Eventually everything will come to a halt and something is going to roll back.  

You can view this link to set up an event monitor to see what's causing the deadlocks:
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/r0000915.htm

Usually commiting more often can clear this up...

Good luck,

- Keith
0
 
aditi1Author Commented:
Thanks Keith, I am working at this direction (trying to monitor and analyze the deadlocks), but what i'm not sure of is how can the application exceed 100% maxlocks value? is there additional parameters that limit the ammount of locks that you think I should check?

Regards,
Adi
0
 
ocgstylesCommented:
Hi Adi,

I just read a bit more on the MAXLOCKS parameter, because I wasn't sure what would actually happen when MAXLOCKS is set that high.  The article suggests that this is a find-a-happy-medium parameter.  Setting too this too low will cause frequent lock escalations among applications only holding a few locks, and setting it too high causes the same effect with the last n percent of applications trying to request only a few locks, since there's not enough room to hold all the row locks they need.  

Here's the help file on that parameter:
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/r0000268.htm

Did monitoring show conclusive results?

- Keith
0
 
aditi1Author Commented:
Hi Keith,

I'm not sure I understand the behaviour you described - I will look at the article see if it makes any sense.
I believe using maxlock of 100% isnt a normal configuration, I just set it to this extreme to see if I still get the same problems.
Anyway we are still working on the monitoring and I will have a pro DBA with me for that so I hope we will figure this out.

Thanks!

-Adi
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.