-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
John,
On 2/18/19 07:45, John Dale wrote:
> I agree - release your connection, commit transaction (if you have
> auto-commit set to false), and null-out your connection
> references.
>
> The analogy in c++ is you need deallocate memory.
Deallocation of memory is a bad analogy, here. The better analogy for
C++ is ... returning a connection to a connection pool in C++. The
general term for this is "resource management", and it's important in
every programming language ever.
> Java has GC in Java at a base level, but we also have some
> resource reclamation at higher levels of abstraction over which GC
> has no purview. Pooling (threads, connections) is an example.
> The connection pool needs to reclaim its connections for
> reallocation to other threads. If it can't, the application will
> hang waiting for connections.
Exactly.
> Do you have a static references to a database connection?
>
> The golden rule with database connections is acquire them late and
> release them early. I like to create try/catch/finally blocks.
You must use try/catch/finally. Otherwise, you will leak resources.
> In the finally block, which executes even if there is an
> exception, I commit the transaction and set connection reference to
> null.
Compilers and static analyzers will often give you dead-store warnings
for null values, but I disagree with them that dead-stores are *bad*.
If you add code to the end of the method which makes the dead-store
into a LIVE-store, but the resource (e.g. ResultSet) shouldn't be used
anymore, it becomes a bug. An NPE is better than a use-after-free
(which isn't really a thing in Java like in other languages, but
practically it can have a similar effect).
I wouldn't always commit the transaction in the finally block. That
can be wasteful at best and incorrect at worst. You commit should
(usually) only occur if no exceptions are encountered. All other
situations (usually) require a rollback.
> As a matter of course, I would null out and close references to
> PreparedStatements and ResultSets as well (especially ResultSets).
This is 100% required for some drivers. The JDBC spec explicitly
allows for drivers to leak these resources if you do not clean them up
properly... especially if you are using pooled-connections (which IS
the case, here). I have seen some drivers (MySQL) which seem to
clean-up the mess and others (Oracle) which can cause problems not
only on the client, but also on the server ("Too many open cursors").
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxrCWQACgkQHPApP6U8
pFhnOhAAvZeMADzrIz3x28CZjjBE2Hw2xEc9pEIeBaJVUTsPkjIHDQdTWNruxasz
NkW8T6hXkHRexoEqq6aLTrjtlaQmOawjvdvDzkF0+b7BvrUSBjAmpB4ai02FSZ/Y
vBvDXFgqthHxPYL9ykP3LlTaV2a4g+noDkVj862++AFhsVzEwZzW3cuQsegwoRs2
pmEFIH9ZxGeD3OM5+2TdzUTdTGyc49OcmmI0UzKRFF1iZxmhBuuBDijvdW0OA+2K
WVq+RhCeqKclAGXOV9OIBSTewQaLVL5fgujlJxRDG7xW3oBsnfOc0SzipDMkXXsy
QpZQGzbx8XnaeEnFE7m5gqL0bxnen31pcrF3NigCPw75rOHbOTxO2pSvlRpSK6xq
WV8Wieytwq0Bc691TnmAibmx5wVMjqiFlXLmzd3wNlVMxHf9NmxmoWNfzqX03YZs
44tj/tko5ukOJcI8oyhDeVKuGA8T57gU0qHl/aAgxunBmCSJiizoPc/8UcR577jj
ZLSrG1Fk/SXa1opzDZyOZbiG8apZX5V3oWmfcmyoLTIq0I46waTDBd3MohWmAm9t
stp0oLlCgmv9ydJK7VptiTXcTBYjfFn5sMEmcBx6Mp+Z3GexaX9gZx5dGNPFMa8v
3LboKGJ27V4mc60g8yUd+4MiK+09xlQcbsILIhCH2mcWy+YOkdo=
=Df7E
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
