I have a 3-tiered application with Glassfish 3.1.2.2, MySQL database and a Swing client application. Is it somehow possible to handle a database server crash?
I tried to stop the MySQL service during my application is running. Then I get javax.ejb.EJBAccessException exceptions everytime I try to access the database through one of my facade session beans.
I want to notify the user that the database is currently down. furthermore i want to set my application in kind of a “sleep-mode” until the database is up and running again.
What would be a good (and possibly easy) approach to handle such a scenario?
Thanks for your help in advance!
A) Ensure you configure Glassfish Connection Pool for automatic recovery/reconnection
In the Glassfish JDBC connection pool configuration, set the values for:
is-connection-validation-required, validate-atmost-once-period-in-seconds, connection-creation-retry-attempts, connection-validation-method, connection-creation-retry-interval-in-seconds, pingGlassfish Configuration jdbc-connection-pool Properties
Glassfish Admin – create-jdbc-connection-pool subcommand
Steps:
http://localhost:4848(or use whatever port you specified during install.B) Implement Application Error Handling / DB Monitoring & Alerts
Mandatory: trap “infrastructure-level” fatal user errors and alert support staff.
Create a simple JMX class to send a notification & call its method
when a fatal error occurs JMX MBean Class which sends notifications. You can use a JMX monitor console to observe state of servers – some of these consoles send email alerts (e.g. JManage and RHQ) and there are bridges for access from HTTP/AJax or other languages (e.g. Jolokia can use javascript/perl/java API to access JMX notifications).
Use Google Calendar API to send the error msg to support staff’s google calendar (1 or 2 mins into future). Then configure google calendar to send email/sms notifications – will give error alert straight to support staff in near-realtime. This is subject to Google usage restrictions (a courtesy limit of 10,000 queries per day, so make sure your apps not super buggy and use logic to limit the number of messages sent in an hour/day/week)
Desirable: monitor DB (& probably app server) and alert support staff of outages
In all cases, setup will not happen instantly – best to implement as a separate mini project & do it right – best to have support staff involved in this.
If these are “out of scope”, then create your own simple monitor: