----- Original Message (edited) ----
From: Michael Ludwig <mil...@gmx.de>
János Löbb schrieb am 24.02.2011 um 11:24 (-0500):
> On Feb 24, 2011, at 10:58 AM, David kerber wrote:
> > On 2/24/2011 10:49 AM, János Löbb wrote:
> >>
> >> What is the very basic structure of a web application that is
> >> connected to a database through a connection pool, but would not
> >> require to restart itself or restart Tomcat when the database goes
> >> down - let say for maintenance ?
> >>
> >> Telling otherwise how to write a webapp that would survive a
> >> database recycling and would not require human interactions to make
> >> it work again.
> >
> > I've never had trouble having my app reconnect after restarting the
> > database; the tomcat db connection classes handle that
> > transparently, AFAIK.
> >
>
> Well, I have here programmers who are writing web applications and
> those are stuck if I recycle the database. Therefore I have to do a 1
> hour hokusz-pokusz, shutting down Tomcat, etc... all over the place,
> before I can recycle the database. So I just would like to know what
> would be the structure or skeleton of the simplest java web app that
> would not die if the database is pulled underneath and would reconnect
> like charm after the database is back again.
Many or most database applications can't do business when the database
is not available. All write operations will fail unless, for example,
going to a message queue. All read operations will fail unless, for
example, tapping into a cache, or another database. What's left to do
for the app when it cannot offer its services to the user? Basically,
display a "temporarily out-of-service" page.
> When I mention them that their programs should handle the situation
> resulting from the database bounce automagically and not the dba
> handling the web app or Tomcat shutdowns and restarts, they look at me
> like I came from Mars or Saturn :-)
>
> So, I just want to know how it is done in the "real world" :-)
I don't know. Various procedures seem possible.
* static maintenance downtime page
* fallback app offering basic functionality reading from a cache
* offering more advanced functionality, writing to a queue
Questionable whether the complexities involved in the latter approaches
will not far outweigh the benefit to the user. I don't think there is a
trivial solution that does more than display a maintenance page.
--
Michael Ludwig
----- Original Message (edited) ----
A conceptual framework for doing this could be:
1. Use Tomcat's provided connection pooling
2. Use a validationQuery in Resource element of context.xml
3. Trap the exceptions when the database is down
4. Handle database connection exceptions by displaying a maintenance page
When the database comes back up, the validationQuery will reestablish database
connectivity and your application should work.
I have a sample application that I use for resource leak testing. It uses Derby
as the database, and the context.xml file looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true">
<Resource
name="jdbc/leakrs"
description="Leaks R Us"
type="javax.sql.DataSource"
auth="Container"
driverClassName="org.apache.derby.jdbc.ClientDriver"
maxActive="10"
maxIdle="3"
maxWait="10000"
password="*****"
url="jdbc:derby://localhost:1527/leakrs"
validationQuery="values(1)"
username="*****"/>
</Context>
When the database is shut down, I get exception messages logged (you do log
exceptions, right?). Pages that depend on database content are missing that
content.
When the database is started up again, a refresh of the pages displays the
content coming from the database.
Better handling of the exception (bubbling up to the controller level) would
allow me to display an appropriate error or maintenance page.
. . . . . just my two cents.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
