Thanks Chris for adding more details and answering Dan's questions. Chris' interpretations are what I was trying to convey.
On Wed, Aug 13, 2025 at 2:56 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > 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 > >
