Dan,
On 8/13/25 12:38 AM, Daniel Schwartz wrote:
-----Original Message-----
From: Robert Turner <rtur...@e-djuster.ca.INVALID>
Sent: Monday, August 11, 2025 10:12 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: How to access a REST service
If one is going to make multiple requests (especially without much logic
in-between), I would suggest reusing the same connection (wrapped with the
relevant resource management logic). Obtaining a connection is a higher cost
operation than a query request, and releasing and reacquiring it requires more
synchronization overhead which can reduce parallelism for handling many
requests at once.
DGS: I don't currently know how to do this, but I think there is a way to identify a user
"session" in the website and then only open one DB connection per session. I
will look into it.
Do *NOT*, under any circumstances, do this.
If you let a user login (or not, maybe you don't require login) and take
a db connection from the pool and not return it until they log-off (or
some suitable timeout occurs), then your application will fall-over
after 2 minutes no matter what your pool configuration is.
Also, what you are suggesting above is that three, non-concurrent connections
are obtained. I'm not sure we got this impression from previous communications.
At least I thought you had three connections open at the same time for the
request. Hence our greater concern.
DGS: The connections are separate and non-concurrent---running in series.
This is completely fine. Robert's advice was if there is an opportunity
to merge these application-data-requests into a single "get connection",
"get data - plural", "return connection" workflow, you could get some
benefit from it. But a single request which performs several of these,
including "get connection" and "return connection" operations during its
lifetime should not be a problem. It's just slightly less optimal from a
performance perspective. Don't worry too much about it unless you see
some low-hanging fruit.
Also, minimizing the time the DB connection is held and obtaining all the data
as quickly as possible makes for more efficient reuse of connections in the
pool when there are many requests contending for the DB connections.
(Avoid holding your DB connections while reading parameters / payloads, or
while responding to the client (as the write back to the click can block)).
DGS: My code isn't holding anything, but Glassfish might be.
Your code looks like this:
Connection conn = getConnection;
// Do some stuff
conn.close();
During the "do some stuff" period of time, your application is "holding
the connection". When you close the connection, it gets returned to the
pool. That's all we are talking about: the "do some stuff" interval.
Robert is recommending that you minimize the time it takes to "do some
stuff". So if you have stuff in there that isn't really working with the
db directly, try to move that code outside of the "get connection" and
"return connection" area. This will get the connection back into the
pool as quickly as possible so it can help serve other requests.
Anyway, different designs are also valid, but that would be my approach.
Especially if you need to deal with a large number of requests in short periods
of time (which if you are peaking at 269, it suggests you are).
DGS: I don't know exactly what that number 269 represents.
This came from one of your previous posts.
If this is a low use system or you aren't really in need of optimizing
throughput and computing resources for high capacities, or the cost of computer
resources is negligible compared to the cost of time to improve efficiency,
then there is no compelling motivation to change it.
DGS: This is my thinking too. But I'm hoping that the website will get a lot
of use in the future, in which case there might be problems.
Better to sort these things out now when you aren't in a panic. :)
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
