On Mon, Aug 09, 2004 at 07:11:24PM -0400, Jignesh Patel wrote: : I want to inform to my application that database server is down so in : turn display appropriate error page to users. As well as all connections : should get closed in the pool.
You're overthinking this. =) When the database is down (or otherwise unavailable) attempts to use DB-related objects (Connection, Statement, ResultSet, etc) will yield SQLExceptions. In turn, that exception (or even better, an app-specific exception that shields code up the chain from datasource-specific exceptions) will get passed back to the presentation layer, at which point you can serve an appropriate error page. For example, assuming a simple Page Controller setup for some use case: your code will do some processing and dispatch to an appropriate view. If the code is successful, dispatch to the "success" page. If you catch a data-related exception, dispatch to the "database error" page. This is why I said before, there's no need to tell the app that the DB is down: it will know. ;) There are certainly other (and more complicated) ways to handle this, which will all do pretty much the same as what I've outlined above. It sounds like you're more familiar with stateful/fat clients that maintain a constant connection to the central server, and that you can send them a message when the DB is down. HTTP doesn't offer such server-push functionality, just client-pull. -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
