One additional set of suggestions for this project or for the future (inline):
On Mon, Aug 11, 2025, 21:53 Daniel Schwartz <d...@danielgschwartz.com> 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. 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. 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)). 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). 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. Robert >
