Hi Christopher , Thankyou muck for the explanation for this !!! we have got from below mail that it is likely to be an application coding issue and they needs to fix or use commit etc for long running transactions .
The one steps that you have given below to set the "query timeout" , is this one we can set up on Tomcat side ? Something else that may help in your situation as a band-aid would be to set a "query timeout" on your connections to abandon any query that takes too long. You could set this to a very long timeout like 60 seconds to ensure that your application, if it does get tied-up like this, will at least eventually become available without you having to restart your application server(s). Thanks & Regards, Priyanka Kumawat | Middleware Admin T +91.7879364483 EMail - priyanka.kuma...@dxc.com DL - ams-leveraged-webadmin-offsh...@dxc.com DXC Technology -----Original Message----- From: Christopher Schultz <ch...@christopherschultz.net> Sent: 19 October 2022 21:28 To: Tomcat Users List <users@tomcat.apache.org>; Kumawat, Priyanka <priyanka.kuma...@dxc.com> Subject: Re: DB2 database locks Priyanka, Before I respond further, database lock problems are almost certainly not being caused by Tomcat itself. It's far more likely that the application(s) deployed on Tomcat are responsible for the problem. Please see below for additional comments. On 10/18/22 14:55, Kumawat, Priyanka wrote: > We have been encountered another issue with the Database locks > recently , yesterday there was been Table locks identified from the > Database team , and after certain period of time we have received the > below error on the Apache logs and we have to restart the > tomcat/Apache instances. > > > : [Mon Oct 17 04:21:04.599196 2022] [mpm_event:error] [pid 10576:tid > 140052698470144] AH00484: server reached MaxRequestWorkers setting, > consider raising the MaxRequestWorkers setting This error message is unrelated to database locks, but if you have locked transactions on the database server, that may cause your application threads to stall and block-up the whole network. > we needed your suggestion as how these errors can cause the Apache to > go with worker exhaustion error. > > Apache version - 2.4.25 Note that this is the Apache httpd version, which is "old" but if you are using a package-managed version might not be actually out of date. You should check to ensure you are running the latest version of httpd, otherwise you may be exposing you and your users to security vulnerabilities. > HOLDAPP HOLDER AGNTHLDLCK WAITTAPP WAITER WTAGNTID > HOLDMODE OBJTYPE TABNAME SCHEMA WTNGSECS > > --------------- ---------- ---------- --------------- ---------- > --------- ---------- ------------------ ------------------------- > ---------- ----------- > > db2bp DB2INST 25726 db2jcc_applicat WING2 26171 U > TABLE_LOCK SALESDOCLI WING2 616 Tomcat can be configured to perform some database operations on your behalf. Among those operations are the following: 1. User authentication 2. Durable session data storage Neither of those, I suspect, would be using a table called "SALESDOCLI" and so I repeat my suspicion that your application is at fault, not Tomcat. There is some good news, though: all the locked tables are the same, so it should be easy to check your application for accesses to that table and see what may be wrong. I highly recommend that you and/or your programmers read this article for more information about database connection resource management: https://clicktime.symantec.com/15tStamh3A9TqmP1AZ3rW?h=HtKkO_1alkGcAx1CwAu6RMqlIgFQDAMkZXZP9O3OwkA=&u=https://blog.christopherschultz.net/2009/03/16/properly-handling-pooled-jdbc-connections/ Something else that may help in your situation as a band-aid would be to set a "query timeout" on your connections to abandon any query that takes too long. You could set this to a very long timeout like 60 seconds to ensure that your application, if it does get tied-up like this, will at least eventually become available without you having to restart your application server(s). Hope that helps, -chris DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.