Thanks for the explanation. This makes things clearer. So both code
examples are correct, but the one in the docs minimizes resource usage?
All db related code I have written so far looked like this:
try {
// db related code with result set loops and more
// db related code done, first possibility to release db objects
} catch {
// error handling
} finally {
// close and release objects
}
// possibly a lot of other code
So I never felt any needs for releasing the resources already in the try
block. But in any case it was important to learn about the possible
impacts when closing the connection improperly in the try _and_ the
finally block.
Thank You
Stefan
Caldarale, Charles R schrieb:
Which solution are you referring to? If it's the one in the Tomcat docs, that
so far still seems the simplest and most obvious to me. What's not shown in
the example is any additional processing that might be done after going through
the result set; if that processing is extensive, it's good to close the various
DB-related objects as early as possible to make the connection available to
other requests. Likewise, nulling out variables allows GC to reclaim the
object space as early as possible. This should be standard practice in any
server-related programming: minimize resource usage. (This is also why you
should close a ResultSet as early as possible, rather than waiting for some
later action to do so indirectly.)
- Request 1 running in Thread 1 gets a db connection.
- Request 1 closes the db connection.
- The JVM switches the running thread to Thread 2
- Request 2 running in Thread 2 gets a db connection (the same db
connection just closed by Request 1).
- The JVM switches the running thread back to Thread 1
- Request 1 closes the db connection a second time in a finally block.
- The JVM switches the running thread back to Thread 2
- Request 2 Thread 2 tries to use the db connection but fails because
Request 1 closed it.
Looks like the above was written in the bad old days of what was called "green threads",
where all Java threads were actually run by a single native thread. The "green threads"
concept thankfully went the way of the dodo quite a few years ago, and there is now a one-to-one
mapping of Java threads to native threads. The above should be adjusted accordingly, but that
would only change the wording, not the intent of the description.
So I'm still confused about the docs.
I'm confused about you being confused; why do you think the example in the
Tomcat docs is overly complicated?
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
---------------------------------------------------------------------
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
