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.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 26 of 41 | next ›
Discussion Overview
groupuser @
postedApr 30, '12 at 9:10a
activeMay 3, '12 at 9:55a



site design / logo © 2022 Grokbase