Chris, Thanks again.
Dan -----Original Message----- From: Christopher Schultz <ch...@christopherschultz.net> Sent: Wednesday, August 13, 2025 2:56 PM To: users@tomcat.apache.org Subject: Re: How to access a REST service 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. DGS: Thanks. I hadn't thought of this. > 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. DGS: Okay, thanks. > 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. DGS: For the first two or three connections, the "do some stuff" part takes only a few milliseconds, and the last one takes only a bit longer because it takes time to do some calculations, but it's quite quick too. > 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. DGS: This number came from the Glassfish monitoring system, which presents numerous data items without explaining exactly what they mean. It is some sort of maximum, but I'm not sure what it maximizes. > 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. :) DGS: Good advice. But at this point, I wouldn't know what else to do regarding Glassfish. Maybe Tomcat is a better option than Glassfish. I will look into this. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
