>> Another option is to use servlets, the converse of "applets" but embedded
>> on the server side. Apache supports JServ (see java.apache.org) which
>> runs standalone alongside the web server. Servlets let you do fancy
>> things which you may want in the future. In particular you could pool
>> your database connections and reuse them from servlet to servlet.
>
>Caveat on pooling database connections in servlets:
>
>You need to make sure those database connections are thread safe. Since
>there is only one instance of a servlet running, you don't want threads
>stealing resources from each other.
>
This caveat holds for *any* stateless machine that can be executed
concurrently (as servlets are, at least within any self-respecting servlet
engine, anyway).
>IMHO though, servlets are very useful, and are my favorite way of doing
>servers in java. Even if you don't plan to access them through a web
>browser.
>
And once you do that, is your web server really *just* a web server, or a
particularly over-specialized form of generic application server.....? :)
How about this: instead of running a web server, run a generic application
server (EJB, CORBA, who cares) that has a "servlet" (sorry to reuse the
term) that listens on port 80, understands HTTP, and hands back HTML
resources? Six of one, half-dozen of the other, you might argue, but most
application servers are starting to go the
clustered/load-balancing/fault-tolerance route, and if your application
server is an EJB server, your HTTP SessionBean can always get swapped out
when there's no HTTP requests.... Try doing *that* with Apache. :)
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
