As far as I am aware, most DBMS's are going to do this. A
JDBC query is an atomic operation with no option to abort processing mod-stream. It triggers processing in the DBMS, and the only real way the DBMS can tell that Tomcat has shut down is that Tomcat's network connections were all dropped. Since DBMS processing is fairly complex and modularized, it's unlikely that the inner workings of the query process in the DB server are going to be aware of the network connections. Not impossible, since loss of connection could trigger a cascade of events down into the DB internal processors, but not likely, since it's extra complexity and thus can make the processing buggier. Also, queries are one thing, but ACID updates and deletes are another - do you roll them back or finish them silently?
It's not really a good idea to run lengthy queries from a webserver, however. Not just because of the problems that you are anticipating, but because web actions are expected to happen interactively and quickly and it takes extra work to code something that can run long-term in a webapp. A better solution, if possible, would be do do the query offline and store the results pre-digested in a result table, materialized view, or something equally amenable to quick interrogation.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.