Hello, my cents on this issue.
Chris's article is fine except that it does not use the try-with-resources
feature of Java language:
try (Connection conn = getConnection()) {
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery(sql)) {
...
}
}
}
That will make sure that every SQL resource is freed correctly.
Other important thing is that you should free the connection as fast as
possible. Don't make long lasting operations while you have the connection
open. Instead you could read the SQL result to memory, close the connection,
and then do additional work.
Third thing is what Chris is also saying, avoid taking more than one connection
at a time. It will end up in deadlock when you run our of connections. And it
also breaks the previous rule.
-Harri
-----Original Message-----
From: Rob Sargent <rsarg...@xmission.com>
Sent: tiistai 5. elokuuta 2025 7.57
To: Tomcat Users List <users@tomcat.apache.org>
Cc: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: How to access a REST service
> On Aug 4, 2025, at 8:11 PM, Daniel Schwartz <d...@danielgschwartz.com> wrote:
>
> Hello Rob,
>
> I don’t know what a “top post” is or why it should warrant an apology, but I
> appreciate your taking the time to reply. This looks interesting.
>
> I’m currently using Glassfish, which has built in connection pooling. I was
> having trouble with its crashing frequently with a message saying that it was
> unable to allocate any more connections. Then I learned that the default
> pool size was only 32 and that this is the maximum allowed number of
> concurrent connections, so I increased this to 1000, and now it runs fine.
> I am new at this, though, and any new info is helpful. Thanks.
>
> Dan Schwartz
1000 is a rather large number of open connections. For one thing they are quite
memory intensive. I suspect you are (still) leaking connections - not re-using
those with which you have completed a database task. You will likely hit the
same error if your system stays up for any length of time.
I recommend going back to Chris’s article to get this leak under control.
PS
This is a bottom post, wherein the new text follows the original.
>>
---------------------------------------------------------------------
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
