|
View previous topic :: View next topic
|
| Author |
Message |
ksouren007
New User
Joined: 30 Jun 2010
Posts: 85
Location: Toronto, ON
|
|
|
|
Hi,
One of my job often fails with -911 contention with the same another job belonging to a different subsystem. I want to do a permanent fix by giving my job an exclusive lock of the table which both of it uses. Please can anybody advice me on how to modify my 'update table' statement in the program so that it gets an exclusive lock and avoids this contention? |
|
| Back to top |
|
 |
ashimer
Active Member
Joined: 13 Feb 2004
Posts: 551
Location: Bangalore
|
|
|
|
So what will happen to the other job when it try to access the table -911 right ? So probably the user in the other subsystem will also be thinking in the same line. Why not schedule the jobs to run at different times ?
You need to lock the table exclusively at the start of your program or before you apply any updates or deletes. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Quote: |
so that it gets an exclusive lock and avoids this contention?
|
and locks-out the other job?
as often is the case, the design is at fault.
exclusive locks should not be used by those who want to implement them without knowing how.
-911's come with a reason code. so start there. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
use IBM's error LookAt Site which will point you to the reference material,
which will tell you where to find the reason code explanations. |
|
| Back to top |
|
|
GuyC
Senior Member
Joined: 11 Aug 2009
Posts: 1281
Location: Belgium
|
|
|
|
LOCK TABLE statement ?
But of course it is still bad practice .
Contention have to be solved at a scheduling level and/or commit frequency. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Suggest you consider changing the design of the conflicting processes. . .
The systems i support do not permit table locking - it is rejected when the process is in the review/promotion process. Why should we go back to single-user mode just because some processes are poorly designed 
A simple "do nothing" solution might be to properly schedule these so they do not run concurrently. . . |
|
| Back to top |
|
|
ksouren007
New User
Joined: 30 Jun 2010
Posts: 85
Location: Toronto, ON
|
|
|
|
Hi,
Thanks for all your help...I am currently working with the other subsystem's scheduler to sort this out...and He's suggesting that we set a dependency to our job on their job as ours is not so critical one...lets see what comes out of it...Thanks a lot again for your help.
Regards,
Souren |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
You're welcome - good luck 
d |
|
| Back to top |
|
|
|
|
