During a sales event the database starts rejecting connections with a too-many-connections error. Investigation shows the application's ORM configuration opens a brand-new database connection for every web request and closes it afterward. Which change is the most appropriate programming-side fix?
Select an answer to reveal the explanation.
Short Explanation
If your app opens a fresh connection per request, that's like hiring a new cashier for every customer and firing them at the door. A connection pool keeps a set of cashiers on shift and hands them out as people arrive. Don't confuse loading strategies with connection handling; they solve different problems.
Full Explanation
Establishing a database connection is relatively expensive: it involves a network handshake, authentication and session memory on the server. An application that opens a new connection per request multiplies that cost and, under load, can exceed the server's connection limit. Connection pooling keeps a bounded set of open connections that requests borrow and return, which caps concurrency at a level the server can handle, removes repeated setup cost and smooths bursts with a short wait for a free connection. ORMs and their drivers expose pool size, timeout and idle settings for this purpose. Enabling lazy loading changes when related rows are fetched, not how many connections exist, and it often adds round trips through the N+1 pattern. Holding a long-running transaction for each request makes contention worse, because each connection and its locks stay occupied longer. Eager loading can reduce the number of statements per request, which is useful for query efficiency, but every request would still open its own new connection and the limit would still be hit. Exam caveat: raising the server's maximum connections is a server-side workaround, not the programming fix the stem asks for. Operational check: after enabling pooling, watch active and idle connection counts during a load test.