Hi Christopher,
I'm agreeing with you about long transaction for a general JEE
application design. But that's probably the one case over a million.
Tomcat is used as the middle tiers server for a jdbc type 3 driver, with
an IDEs as a front-end. In this situation we know transaction can be
longer than application ones (if we exclude conversation patterns).
This solution helps us a lot to enforce security on "direct" databases
accesses (maintenance, data fixing, ...). It also provides a very
usefull audit trail.
Transactions were really too long because some users forgot to commit
(or rollback) their work, on several parallel connections... As I was
doing the first runs of a new JS application at the same time, I though
it was this new application.
Stephane
Le 2022-07-06 à 23:37, Christopher Schultz a écrit :
Stephane,
On 7/6/22 07:12, Stephane Passignat wrote:
Thanks for your help. I found that someone else was freezing the API
server through the database (very long running uncommitted
transactions).
That'll definitely do it.
This kind of thing isn't going to work in the real-world: tying-up a
database with a transaction that lasts even a few seconds is going to
absolutely kill your performance.
You need to work with that other group to figure out why they need
long-running transactions and figure out how to solve the problem in a
different way.
You should also protect yourself and set timeouts on writes that, if
they fail, they fail "fast" and don't appear to freeze. You should be
able to detect a write-timeout and reply to the API user saying
"sorry, write failed after N ms" or something like that. Otherwise,
you run the risk of a single uncommitted transaction stalling your
entire business while writes pile-up. Users tired of waiting will
re-request the same write over and over again. When the initial
transaction finally commits, you'll have a huge storm of writes
hitting your database all at the same time. It will be a mess.
Anyway I also limited the number of parallel connections on
javascript side (axios).
This is always an excellent idea. There is no reason for a single
client to be making huge numbers of queries to your database
simultaneously.
-chris
Le 2022-06-30 à 18:42, Christopher Schultz a écrit :
All,
On 6/30/22 02:34, Mark Thomas wrote:
Hi,
We need more information to help you.
Tomcat version?
Tomcat connector configuration (from server.xml)?
httpd version?
httpd MPM and configuration?
mod_proxy configuration?
Was the httpd restart graceful or not?
Wild guess: missing finally { java.sql.Connection.close(); }
-chris
On 29/06/2022 19:36, Stephane Passignat wrote:
Hello,
I'm creating a SAP application performing REST call on an API
running on Tomcat. Tomcat runs behind an apache reverse-proxy and
communication between them use http. The calls are executed with
axios using a basic authentication.
Everything runs fine for a moment, but for an unknown reason all
http request are hanging after some time and hundreds or maybe
thousands requests (if these metrics make any sense).
In chrome, the requests are in a 'pending' status.
Restarting chrome allows to do one or two requests and then issue
occurs again
Restarting apache doesn't change anything.
Restarting Tomcat resolve the situation. Tomcat shutdow is a bit
longer. Request in chrome ends when tomcat stops.
I'm not very inspired by this issue and actually trying to find
inspiration in jmx and log files but nothing pops up.
Does someone have an idea ?
thanks
Stephane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
