This content has been marked as final. Show 2 replies
Yes, the various notification mechanisms that inform the user of membership status changes are the right way to go. You've already noticed the Monitor and MonitorChangeListener classes, and I hope the javadoc (start with com.sleepycat.je.rep.monitor.Monitor) and the chapter in the replication guide are informative enough: http://docs.oracle.com/cd/E17277_02/html/ReplicationGuide/monitors.html. Also note the chapter on using com.sleepycat.je.rep.StateChangeListener: http://docs.oracle.com/cd/E17277_02/html/ReplicationGuide/replicawrites.html.
The two mechanisms differ from the perspective of whether the handling is done at the point when the application has access to a ReplicatedEnvironment, or whether it's done by a third party entity, like a load balancer. They're two sides of the same coin. But neither one can totally exempt the application code from needing to handle the possibility of an InsufficientReplicasException.
- It's always possible that the notifications will be delivered and handled later than the exception
- the lack of a response from a replica might be due to a temporary network glitch, and since there hasn't been a true state change, no notification is sent
- if a node fails, it can't send its own notification, of course, and it can take a little while for other nodes to step in, detect the state change, and manufacture a notification
So the notification mechanisms can optimize and reduce the possibility of getting an InsufficientReplicasException, but it can't completely remove it. This does lead to the need to handle a variety of exceptions in the application code. A long time ago, Jeff Alexander wrote up this example of how he made a transaction wrapper to modularize all the exception handling: https://blogs.oracle.com/jhalex/entry/handling_transactions_in_bdb_je. We tend to do something along those lines when we write code that is issuing data operations against a BDB JE HA cluster.
Hope that helps,