-----Original Message----- From: Robert Turner <[email protected]> Sent: Monday, August 11, 2025 10:12 PM To: Tomcat Users List <[email protected]> Subject: Re: How to access a REST service
One additional set of suggestions for this project or for the future (inline): On Mon, Aug 11, 2025, 21:53 Daniel Schwartz <[email protected]> wrote: > > DGS: A single simple query to my interface requires three database > accesses, one to retrieve a list of countries, then, when the use > selects a country, another database access to get the lists of states > and cities associated with that country, and then assuming the > simplest case where there are no states or cities, then a third > database access when the user enters a year and requests the holidays > for that country in that year. If there are states selected, then a > fourth database access is required to get the cites for that state or to > determine that there aren't any. > 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. 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. 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. 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. 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. Robert > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
