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://www.google.com/url?q=https://www.cockroachlabs.com/blog/what-is-connection-pooling/&sa=U&sqi=2&ved=2ahUKEwjYm7y42vGOAxV5OzQIHRYbJswQFnoECBUQAQ&usg=AOvVaw3CwmC-QEJojMaYtOvsdRes > On Aug 4, 2025, at 10:31 AM, Daniel Schwartz <d...@danielgschwartz.com> wrote: > > Hello Chris, > > Thanks. This looks helpful. > > Dan Schwartz > > -----Original Message----- > From: Christopher Schultz <ch...@christopherschultz.net> > Sent: Monday, August 4, 2025 10:15 AM > To: 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> >> Sent: Friday, August 1, 2025 5:32 AM >> To: 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 >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
