tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <>
Subject RE: programming question
Date Fri, 25 Feb 2011 19:20:09 GMT

michael is correct..if your db goes down there is nowhere to persist your data objects to
and there is nowhere to query the data from

Have you considered writing to a database cluster?

MySQL Clustering:

Oracle RAC:

Any other Database clustering technology?
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten
wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist
unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet
keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen
wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire
prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe
quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information
seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les
email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune
responsabilité pour le contenu fourni.

> Date: Fri, 25 Feb 2011 20:09:00 +0100
> From:
> To:
> Subject: Re: programming question
> 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message