tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Wadkin <j.wad...@hud.ac.uk>
Subject RE: Database servlets
Date Mon, 11 Feb 2002 15:14:55 GMT
Randy,

Many thanks - final post!

I'll review the code and make it talk!

Re:

Generally you are going to want to use transactions to solve
database concurrency problems (i.e. removing rows others need, etc).  You
can use connection.setAutoCommit(false) and then connection.commit/rollback
to control transactions.

I guess this is what banks do - all or nothing. Ensures integrity of data.
Complicated stuff. I'll stick to the database development and leave coding
to the programmers :)

Thanks,
 
John
 

-----Original Message-----
From: Randy Layman [mailto:randy.layman@aswethink.com]
Sent: 11 February 2002 13:56
To: 'Tomcat Users List'
Subject: RE: Database servlets




> -----Original Message-----
> From: John Wadkin [mailto:j.wadkin@hud.ac.uk]
> Sent: Monday, February 11, 2002 9:34 AM
> To: 'Tomcat Users List'
> Subject: RE: Database servlets
> 
> 
> button in our browsers. Sophisticated, eh? On my machine the 
> servlet worked
> fine, but on my colleague's machine the servlet stopped when 
> dropping the
> table. No errors anywhere. I'm guessing that this is because 
> my request
> removed the table first or/and closed the connection. If so, 
> then the issue
> becomes one of "how to stop that happening" or "how to handle 
> the fact that
> this has happened". It makes sense that one request might 
> "pull the rug from
> under" another request - i.e. alter a shared table. I guess 
> that the SQL in
> the servlet is "unusual" in that it isn't normal practice to 
> remove tables
> (e.g. delete the "customer" table)! I think it's fair to say 
> that it's good
> practice to check that something exists first before trying 
> to do something
> with it (!) - i.e. I'd check that the table existed before 
> trying to delete
> it.
> 

	And suddenly everything become clear.  The dropTable method should
probably throw its SQL Exception or somehow report that a problem has been
encountered (really all your methods should).  The DROP TABLE command will
have caused an exception to be thrown that you never report, that's why you
don't see any notice that a problems happened.

	Generally you are going to want to use transactions to solve
database concurrency problems (i.e. removing rows others need, etc).  You
can use connection.setAutoCommit(false) and then connection.commit/rollback
to control transactions.

	Randy

--

--
To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>


Mime
View raw message