Hello again Rob, I just read that article you referenced by Cockroach Labs. I found the statement:
"If we make the pool too small (i.e. choose too few connections), we’ll introduce latency, as operations have to wait for an available connection to open up before they can execute." This implies that if the number of concurrent accesses exceeds the number of connection objects in the pool, then the system simply waits until some of the currently active connections terminate and the connection objects become available. This is not what was happening with Glassfish. When the number of simultaneous requests exceeds the pool size, the system outputs an error message and crashes. It doesn't just wait until some active connections terminate so that the connection objects become available. It seems that different pooling systems have different policies. Dan Schwartz From: Rob Sargent <rsarg...@xmission.com> Sent: Monday, August 4, 2025 1:49 PM To: Tomcat Users List <users@tomcat.apache.org> Cc: Tomcat Users List <users@tomcat.apache.org> Subject: Re: How to access a REST service Another top post apology. If this is your first Java/database rodeo you might want to look at why pools are a good idea and whether or not they fit your need. Maybe here: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_url-3Fq-3Dhttps-3A__www.cockroachlabs.com_blog_what-2Dis-2Dconnection-2Dpooling_-26sa-3DU-26sqi-3D2-26ved-3D2ahUKEwjYm7y42vGOAxV5OzQIHRYbJswQFnoECBUQAQ-26usg-3DAOvVaw3CwmC-2DQEJojMaYtOvsdRes&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=e7w4teh9aIQALHe76U1py0iyqtcjXfx02vzzglOFkc9dh0BgfasDq2oRvIzwK7x-&s=_UWjBLunOHYm7UwZkR5lAR4MUYt2NLMH0w-75mkZZrc&e= NkdkJdXPPEBannerStart Be Careful With This Message From (Rob Sargent <rsarg...@xmission.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f2ebf5c9af87d45b424babbbc37daee570ddbcd67c5c68ab379532cb66ab114de01fd9c37e8c61332c8ea1c93987de7e6e2237d38978c92d8e5bd9b5ef7c7c5a4e56b9c36a9347726e69a42772382671b484352203aca56dccb5b8f82aab573aaa485a5c26a75d957ea7cfcf526b1163e259bf5d16dc1cc5a6a59bc88574e12d5aeffda19710131b21fc8121ce924f7373f3bf532bfd26c8c19f7bbf1bbac5e15a4e7e1514f73078722852bad09f7e1b85f27a8cd23abacc73b555597358d6786ebe4cced3771c4c6675226e333b5fbcc104a3e71b9a7db970557831dbd194d1bf5c08d5c74d5c2d8> Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f2ebf5c9af87d45b424babbbc37daee570ddbcd67c5c68ab379532cb66ab114de01fd9c37e8c61332c8ea1c93987de7e6e2237d38978c92d8e5bd9b5ef7c7c5a4e56b9c36a9347726e69a42772382671b484352203aca56dccb5b8f82aab573aaa485a5c26a75d957ea7cfcf526b1163e259bf5d16dc1cc5a6a59bc88574e12d5aeffda19710131b21fc8121ce924f7373f3bf532bfd26c8c19f7bbf1bbac5e15a4e7e1514f73078722852bad09f7e1b85f27a8cd23abacc73b555597358d6786ebe4cced3771c4c6675226e333b5fbcc104a3e71b9a7db970557831dbd194d1bf5c08d5c74d5c2d8> Potential Impersonation The sender's identity could not be verified and someone may be impersonating the sender. Take caution when interacting with this message. NkdkJdXPPEBannerEnd Another top post apology. If this is your first Java/database rodeo you might want to look at why pools are a good idea and whether or not they fit your need. Maybe here: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_url-3Fq-3Dhttps-3A__www.cockroachlabs.com_blog_what-2Dis-2Dconnection-2Dpooling_-26sa-3DU-26sqi-3D2-26ved-3D2ahUKEwjYm7y42vGOAxV5OzQIHRYbJswQFnoECBUQAQ-26usg-3DAOvVaw3CwmC-2DQEJojMaYtOvsdRes&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=e7w4teh9aIQALHe76U1py0iyqtcjXfx02vzzglOFkc9dh0BgfasDq2oRvIzwK7x-&s=_UWjBLunOHYm7UwZkR5lAR4MUYt2NLMH0w-75mkZZrc&e= > On Aug 4, 2025, at 10:31 AM, Daniel Schwartz > <d...@danielgschwartz.com<mailto:d...@danielgschwartz.com>> wrote: > > Hello Chris, > > Thanks. This looks helpful. > > Dan Schwartz > > -----Original Message----- > From: Christopher Schultz > <ch...@christopherschultz.net<mailto:ch...@christopherschultz.net>> > Sent: Monday, August 4, 2025 10:15 AM > To: users@tomcat.apache.org<mailto:users@tomcat.apache.org> > Subject: Re: How to access a REST service > > Daniel, > > Apologies for top-posting, but I would highly recommend reading this: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.christopherschultz.net_2009_03_16_properly-2Dhandling-2Dpooled-2Djdbc-2Dconnections_&d=DwIDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=064mdQS9YsKOGXjo7gBDQ2Mi-puZWT6oWPOKTs_HzFX46_g9-I_RzQ4NZsP5yFkU&s=asZCa1h2Ah3YYzVVNf_SaATQFdLYcoF_wkrSSt6a-Nw&e= > > -chris > >> On 8/1/25 3:33 PM, Daniel Schwartz wrote: >> Hello Thorsten, >> >> Please see my replies below, marked DGS. >> >> -----Original Message----- >> From: Thorsten Heit >> <heit_tom...@icloud.com.INVALID<mailto:heit_tom...@icloud.com.INVALID>> >> Sent: Friday, August 1, 2025 5:32 AM >> To: users@tomcat.apache.org<mailto:users@tomcat.apache.org> >> Subject: Re: How to access a REST service >> >> Hi, >> >>> Daniel, >>> You might take a look at java’s “ try with” construct >> >> DGS: Someone else recommended this. I will look into it. I see that an >> issue with my current code is that the database connection won't be closed >> if an error is thrown. >> >> This is an important step, indeed: >> >>>> Here is a fragment of the code from the file HolidaysRESTJSONResource.jar. >>>> -------------------------------------------------------------------- >>>> - >>>> ----- public class HolidaysRESTJSONResource { >>>> >>>> DataSource dataSource; >>>> >>>> public HolidaysRESTJSONResource() { >>>> dataSource = DataSourceSingleton.getInstance().dataSource; >>>> } >>>> >>>> @GET >>>> @Path("/countries") >>>> @Produces(MediaType.APPLICATION_JSON) >>>> public String getJsonCountries() { >>>> ... >>>> Connection connection; >>>> try { >>>> connection = dataSource.getConnection(); >>>> TempDataStorage.countryList = >>>> GetCountryList.doIt(connection); >>>> connection.close(); >>>> ... >>>> } >> >> A couple of questions: >> >> 1) How often is your class instantiated/created? Is it a singleton? A new >> one per each incoming request? >> >> DGS: It is created with every database query. For each user query there can >> be 1-3 database queries, and the same user can make an unlimited number of >> queries. I know it would be better if I could somehow identify a "user >> session" and only create one connection per session, but I don't know how to >> do this. >> >> 2) What happens in case of an exception in your try block? Looking at >> the above snipped the connection isn't closed. >> >> DGS: Yes, that's an issue, which I have noted in the foregoing. I'll change >> to the "try-with" approach. >> >>>> The constructor for HolidaysRESTJSONResource creates a DataSource by >>>> creating an instance of the following DataSourceSingleton class and >>>> retrieving the value of the DataSource instance variable. I >>>> borrowed this code from somewhere. It seems to work. The MySql >>>> database is called "holidays". >> >> 3) Have a look at the version of the database driver you're using. Is >> there perhaps a newer one? If yes, have a look at the release notes >> and check the changes. Perhaps there's a leak in the driver itself...? >> >> DGS: I'm using the latest MySQL 8 driver. >> >>>> Back in HolidaysRESTJSONResource, in the method getJsonCountries(), >>>> the DataSource object, called "dataSource", is used to create the >>>> connection object, and this is used in a method call >>>> GetCountryList.doIt() to retrieve a list of countries from the >>>> database. Then this connection object is closed. I think that this >>>> is all that is needed to prevent memory leaks. Is this correct? I >>>> do this for every such method call that accesses the database. >> >> AFAICT only in case of proper execution wrt to the code snippet >> presented. In case of an exception during the #doIt(...) call this >> won't happen (correctly) and can result in a memory leak (AFAIK). >> >> DGS: Good point. The doIt() method can throw an exception. I will look >> into this. >> >> What happens in case of multiple simultaneously incoming requests? >> Does your database (and driver) allow enough parallel connections so >> that each request is processed correctly? >> >> DGS: I have the Glassfish database connections maximum pool size set to >> 1000. This seems to be enough. When I submitted this question, the system >> was crashing occasionally, but then I noticed that the pool size had >> inadvertently been reset to the default 32. This must have happened when I >> reinstalled Glassfish and then neglected to update pool size. It seems to >> be working now. No crashes in the last day. >> >> DGS: Thanks for taking the time to respond. Do you know of a way to >> identify the start and end of a user session? >> >> Regards >> >> Thorsten >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: >> users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> >> For additional commands, e-mail: >> users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: >> users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> >> For additional commands, e-mail: >> users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: > users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: > users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org> >
