Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
If you had to audit a Java application for worst-practices when it comes to high-availability and disaster recovery, you would probably look for hardcoded IP addresses and suboptimal caching of bind handles. What else should be considered?
Lack of action/state logging.
A Java application should be able to resume where it was when it crashed.
That means there should be a mechanism able to record what has already done (in order to not do everything all over again at the next run).
That also means such a Java program should always achieve the same state after the same set of actions. (Doing something twice would result in the same result, and the actions already done should not be done again, but simply skipped)
That record can take many form (file, database, metadata in a repository of sort, …), but the point is: a Java application willing to recover as fast as possible should know what it has already done.