Daniel,
Apologies for top-posting, but I would highly recommend reading this:
https://blog.christopherschultz.net/2009/03/16/properly-handling-pooled-jdbc-connections/
-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
