Hello Chris, Have you actually tried out my website: www,worldholidaysandevents,com [replace commas with periods]. If you see how it works, this might answer many of your questions. More comments below.
Dan -----Original Message----- From: Christopher Schultz <ch...@christopherschultz.net> Sent: Thursday, August 14, 2025 9:21 AM To: users@tomcat.apache.org Subject: Re: How to access a REST service Dan, On 8/12/25 10:52 PM, Daniel Schwartz wrote: > If you go to my website, > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.worldholidaysa > ndevents.com&d=DwIDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=oFNq_hrTBDUEKGoGwwKZtrn1fzqspMlEAI2L0cMrH4mEdjIFrgaTHKJCPajHdgtQ&s=QlPiDJ5MIOpt_OBVEqbGa2ImGuhP6xb97mlrh7uXKCU&e=, > and make a request for holiday info for, say, Tallahassee, Florida, USA, > 2025, you will see the following actions: > > 1. The Countries list is filled with a list of countries. This is one > DB connection. > > 2. When you select United States of America, the States and Cities lists > are filled with US states and cities. This is one more DB connection, > actually two queries in one connection. Great. Any time you know you must perform multiple db-related actions, you should definitely do them with a single connection all at once. DGS: This would be impossible unless I group these requests into a user "session", which I have been advised by someone, maybe you, is not a good idea. The problem with this is that the "session" could remain open for a long time, thereby keeping the DB connection officially active even though it's not being used. I agree that this is something I wouldn't want. > 3. When you select Florida from the States list, then the cities list is > refilled with just Florida cities. This is one more DB connection. Yes and no. "When you select" implies that there is user interaction. For a web application, "user interaction" means "request is made from client (browser) to server (your application running in Glassfish/Tomcat)". From the perspective of your code, each of (1), (2), and (3) is a single connection in a single request. When you click "Florida" on your page, you are not repeating queries (1) and (2) again before proceeding to (3). Only (3) is performed, and only requires a single connection to do so. If you *are* repeating (1) and (2) before (3), you might consider whether or not it's necessary to do so. DGS: I am not repeating anything. Look at the website and you will see how it works. > 4. When you select 2025 as the year and click “Explore” this is another > DB connection, calculating dates and returning the list of holidays and > events. I'm assuming that this operation gets a connection, gets all necessary data, then returns the connection. After that it does whatever other preparation is necessary to return the response to the client, and then the request-response workflow is complete. This should also only take one connection. Everything you described above should be possible with a single connection in the pool. If your pool grows in development with only you making serial requests, then "something else" is going on. DGS: Again, this would only be possible by associating those connections with a user "session", which I have been told is a bad idea. > So the way the system currently operates, all these DB connections are > necessary. However, if there were some way to identify a user “session”, > then all of these queries could be carried out in one session and with only > one DB connection per session. Probably there is a way to do this, but I > haven’t explored it yet. Right now, if you run these operations, you’ll see > that the response is very quick. However, I don’t know what might happen if > I were to get a lot of users. Assuming that "session" above means "HttpSession" then definitely do not do this. You want a connection to be out of the pool for as short a time as possible. DGS: Right. It *was* you that advised me not to do this. I appreciate the insight. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
