|
View previous topic :: View next topic
|
| Author |
Message |
sandy_venkat
New User
Joined: 16 May 2007
Posts: 35
Location: India
|
|
|
|
Hi Guys,
I am facing an issue wherein I get a -911 (timeout) due to locks. I am getting the following code 00C9008E.
In my case a JAVA program calls a stored procedure. This stored procedure links to a CICS program. All the main logic is in this CICS program.
There are many select and update queries in this program. Depending on what action code the JAVA sends, we perform that particular functionality from the Stored proc.
In this particular call where a print functionality needs to be invoked by STP, there are few updates queries written on 3 to 4 tables. The first update runs fine i.e we do not get any error there. But when the next table tries to get updated I get the above issue. Both the udpates are on two different tables.
When I run the same query though QMF or SPUFI, it executes fine without any problems but when it is executed thru STP, we face a issue.
The stored proc has a COMMIT ON RETURN YES. SO none of the changes get commited till the STP has ended properly.
Could you please help me out with this one as this has been pending since quite sometime now.. |
|
| Back to top |
|
 |
muthuvel
Active User
Joined: 29 Nov 2005
Posts: 217
Location: Canada
|
|
|
|
| I think proper COMMITS in the table will solve your problem. |
|
| Back to top |
|
|
ashok_uddaraju
New User
Joined: 21 Feb 2007
Posts: 72
Location: US
|
|
|
|
| Increase the number of commits by including it after each possible update |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| Increase the number of commits by including it after each possible update |
Commits should be done at logical places, not every update. If 6 of 11 updates have been done and committed and then the process is aborted or otherwise terminated, the data in the database is not valid. |
|
| Back to top |
|
|
sandy_venkat
New User
Joined: 16 May 2007
Posts: 35
Location: India
|
|
|
|
Hi, I agree with what Dick says here. This is an existing piece of code thats giving a problem. The STP card says' COMMIT ON RETURN YES. When I enquired with the DBA here, they said that COMMIT ON RETURN NO is the standard set here. In that case I need to give proper commits at logical points. The code here is such that if I put commits at every update then if the prog abends at some point then the database will have inconsistencies. Hence I need to check how to code this logic again.
Would including commits in proper places solve the pbm?
I wanted to know whether this problem could be a one being caused in the TEST region but would execute fine in the PRODUCTION region? Can that be assumed and the code be moved to production? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
I wanted to know whether this problem could be a one being caused in the TEST region but would execute fine in the PRODUCTION region? Can that be assumed and the code be moved to production?
|
It would depend on what is the exact cause(s).
When the timeout/lock happens in test, how many copies of the code are running concurrently?
I would expect that there will be more concurrent threads in Production than Test, so if the problem is concnrrent processes the problem may increase in Production. |
|
| Back to top |
|
|
|
|
