> But maybe I'm misunderstanding what "standalone" means. > Does it mean Swing? Or a daemon with no UI? Or an > application which needs to be a double clickable > executable but still serves web pages?
In the sense that I understand the word, the first two would usually be designed as a standalone (J2SE) app and the latter one as a container (J2EE) app. > In all three cases, Tomcat/Jetty/etc could still be > part of the solution. Could, but often wouldn't. Tomcat etc. are built for high concurrency. Which means ultra-short transaction and connections and many parallel connections. That's the use case for containers and connection pooling. If high concurrency is not an issue, you could have just a handful of Swing application banging on the same database, or even just a sole daemon. In these scenarios, you don't need the container for its high-concurrency guarantees. Of course that doesn't mean that a container would necessarily be useless in such scenarios. A container enforces a design that makes retrying transactions easier, a connection pool ensures that that broken connections will be recreated ASAP. Both services may or may not be useful to a "standalone" (i.e. non-web-based) application.
