tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Layman <randy.lay...@aswethink.com>
Subject RE: Servlet/ Database Conenction Persists Question
Date Tue, 07 Aug 2001 20:04:17 GMT


> -----Original Message-----
> From: A.L. [mailto:amoslieber@yahoo.com]
> Sent: Tuesday, August 07, 2001 4:23 PM
> To: tomcat-user@jakarta.apache.org; andrewdrobson@netscapeonline.co.uk
> Subject: RE: Servlet/ Database Conenction Persists Question
> 
> 
> Andrew,
>    Thank you for your response.  I appreciate you
> clarifying the topic, nevertheless it seems to me a
> little troubling to assume that the servlet should
> only be destroyed by the servlet.   (I'm new to
> servlets, but by servlet engine, I am assuming you
> mean tomcat).
> 
>    Here is why.  Lets say there is an application
> whose web interface is run by servlets, while the
> desktop app isn't.  If there is a problem with the
> database which needs to be fixed I would ahave to stop
> tomcat so that I may gain complete access to the
> database.  In Microsoft Access for example I cannot
> enter design view if a servlet has an existing
> connection.  Which means I will have to stop the
> complete web application even though the only part
> which needs to be destroyed is the servlet with the db
> connection.   i would like to destroy the servlet
> temporarily, and then reinitialize it via the web.
> Would this be possible?
> 
> 

	Your problem seems to be more of a lack of distributed systems and
client/server programming knowledge in general rather than the specifics of
Servlet programming.  A desktop application is just that, it runs on a
desktop when a user needs it, etc.  A web SERVER, however, is always on,
always waiting for users to give it actions to perform.

	I've dealt with this type of problem in two different ways (and
there are probably others out there).  

	The first is to shut down Tomcat.  Generally if I'm changing the
schema then I'm performing a long lasting update that might take a few
minutes to a few hours.  During that time I don't want users working with a
partially updated database, usually with either new or old code.

	The second way that I have dealt with this problem (and possibly
more applicable in your case) it to encapsulate the database access into an
underlying component with static fields.  Then, I create a database
controller servlet.  This servlet usually takes request like
controller?action=startup or controller?action=stop that would create the
database connection pool, drop all the actives (you need to think about what
to do if something is using the database here), reload configuration, etc.

	Another thing you need to be warned about is using Access.  I assume
you are using it because you mention it.  This is a pretty bad choice for a
server-based product for a number of reasons, not the least of which deals
with the concurrency problems of the JDBC-0DBC bridge (you can find more
information about that either in the archives or on Sun's Bug Parade).

	Randy

Mime
View raw message