Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of mgainty@hotmail.com designates
 65.55.111.108 as permitted sender)
Message-ID: <BLU142-W5F228F21DC8E1395450DBAEDD0@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_ca53aa0e-ab19-4ef2-ba02-360947ab3926_"
From: Martin Gainty <mgainty@hotmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Subject: RE: programming question
Date: Fri, 25 Feb 2011 14:20:09 -0500
Importance: Normal
In-Reply-To: <20110225190900.GB352@wladimir>
References: 
 <635C1285-27DD-498D-95DD-D7F8E1FC0A1F@yale.edu>,<4D668010.1090104@verizon.net>,<493EC8B2-6451-408A-9495-4931A4DCEF05@yale.edu>,<20110225190900.GB352@wladimir>
MIME-Version: 1.0

--_ca53aa0e-ab19-4ef2-ba02-360947ab3926_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


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

Have you considered writing to a database cluster?

MySQL Clustering:
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-replication.html

Oracle RAC:
http://www.oracle.com/technetwork/database/clustering/overview/index.html

Any other Database clustering technology?
Martin--
______________________________________________=20
Verzicht und Vertraulichkeitanmerkung/Note de d=E9ni et de confidentialit=
=E9
=20
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaeng=
er sein=2C so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiter=
leitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient l=
ediglich dem Austausch von Informationen und entfaltet keine rechtliche Bin=
dungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen w=
ir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut =EAtre privil=E9gi=E9. Si vous n'=EAtes=
 pas le destinataire pr=E9vu=2C nous te demandons avec bont=E9 que pour sat=
isfaire informez l'exp=E9diteur. N'importe quelle diffusion non autoris=E9e=
 ou la copie de ceci est interdite. Ce message sert =E0 l'information seule=
ment et n'aura pas n'importe quel effet l=E9galement obligatoire. =C9tant d=
onn=E9 que les email peuvent facilement =EAtre sujets =E0 la manipulation=
=2C nous ne pouvons accepter aucune responsabilit=E9 pour le contenu fourni=
.


> Date: Fri=2C 25 Feb 2011 20:09:00 +0100
> From: milu71@gmx.de
> To: users@tomcat.apache.org
> Subject: Re: programming question
>=20
> J=E1nos L=F6bb schrieb am 24.02.2011 um 11:24 (-0500):
> > On Feb 24=2C 2011=2C at 10:58 AM=2C David kerber wrote:
> > > On 2/24/2011 10:49 AM=2C J=E1nos L=F6bb wrote:
> > >>=20
> > >> What is the very basic structure of a web application that is
> > >> connected to a database through a connection pool=2C but would not
> > >> require to restart itself or restart Tomcat when the database goes
> > >> down - let say for maintenance ?
> > >>=20
> > >> Telling otherwise how to write a webapp that would survive a
> > >> database recycling and would not require human interactions to make
> > >> it work again.
> > >=20
> > > I've never had trouble having my app reconnect after restarting the
> > > database=3B the tomcat db connection classes handle that
> > > transparently=2C AFAIK.
> > >=20
> >=20
> > Well=2C 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=2C shutting down Tomcat=2C etc... all over the place=
=2C
> > 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. =20
>=20
> Many or most database applications can't do business when the database
> is not available. All write operations will fail unless=2C for example=2C
> going to a message queue. All read operations will fail unless=2C for
> example=2C tapping into a cache=2C or another database. What's left to do
> for the app when it cannot offer its services to the user? Basically=2C
> display a "temporarily out-of-service" page.
>=20
> > 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=2C they look at m=
e
> > like I came from Mars or Saturn :-)
> >=20
> > So=2C I just want to know how it is done in the "real world" :-)
>=20
> I don't know. Various procedures seem possible.
>=20
> * static maintenance downtime page
> * fallback app offering basic functionality reading from a cache
> * offering more advanced functionality=2C writing to a queue
>=20
> 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.
>=20
> --=20
> Michael Ludwig
>=20
> ---------------------------------------------------------------------
> To unsubscribe=2C e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands=2C e-mail: users-help@tomcat.apache.org
>=20
 		 	   		  =

--_ca53aa0e-ab19-4ef2-ba02-360947ab3926_--