Dymytry, твой вопрос - на мильон багсов и на целый курс обучения.

Есть шаблон проектирования. Он касается реакции системы в целом на временно-недоступный
датасорс к примеру. Обычное (99%) шаблонное решение - это повтор операции. Который в сетевых
условиях приводит к финализации размера пулов и в забивании "листенера" бесполезными
попытками. И как следствие - приводит к долгим трудно устранимым условиям на "другой стороне".
Это - неправильный шаблон. И его нельзя использовать. По хорошему нужен глобальный
евент который оповещает вашу систему о том что не стоит DDOS-ить свою-же БД до
тех пор пока неисправность не будет целиком устранена.

Я буквально недавно был на семинаре посвящённом этим шаблонам вобщем если вспомню - расскажу
хотя-бы его название.

По поводу 3х потоков. Это решение решает столько-же проблем сколько и создаёт новых. К сожалению
достатчно только сказать что оно "умножает" количество состояний системы и вводит новый уровень
недетермизима который раньше с 1 поточным приложением вам не грозил в принципе. Оно трудно
тестируемо (практически я скажу что его никто не тестирует).

Из коробочных решений можно вобщем-то брать любой сервер приложений и в режиме кластера
считать что вы порешали ошибки (3) и (4).

Basil A. SidorovРазвели тут хайлоад ...
Ресурсы более-менее современного компьютера таковы, что в 64-разрядных системах, при хоть сколько-нибудь пряморуком программировании, одна-единственная JVM в состоянии сделать всё, что нужно на большинстве задач.
Поэтому пишете "стандартное многопоточное приложение" и решаете проблемы по мере их поступления.
Я-бы просто добавил к тезису что если мы решаем проблемы потенциального краша
процесса jvm по причине утечек объектов ОС (сокеты, хендлы мьютексы) то
нужно строить структуру из многих уровней. Должен быть мастер-процесс или
мастер-демон который делает heartbeat и контролирует uptime всех workers.
Нужно также более строгое (основанное на цифрах) и на теории надёжности
систем доказательство того что данный бутерброд из технологий будет
БОЛЕЕ надёжен чем простой однопоточный софт.

Если у нас таких цифр нет и всё базируется на гипотезах то может ну его нафих.
Лучше следовать принципу KISS и делать простой 1-поточный последовательный демон.
А когда будет статистика по авариям - то обсуждать возможную декомпозицию
задачи на независимые части. Анализировать ЧТО. ПОЧЕМУ. КАК ФИКСИТЬ. и т.д.

Dymytrymayton,
спасибо за интересный ответ!

Честно говоря, не совсем понятно что плохого в варианте с тремя потоками.
Тут кстати о чем мы говорим - о трех процессах (трех запущенных JVM) или о трех потоках (три Thread)? Какой вариант лучше?

Еще было бы интересно увидеть любые ссылки на материалы по шаблонам проектирования. Может книги, еще что-то?
Вроде это.

http://www.slideshare.net/IzzetMustafaiev/

Презентация называется Fault Tolerance ... e.t.c.

Паттерны Circuit Braker и библиотеки и фреймворки jrugged, Hystrix.

По библиотекам я вряд-ли что-то толковое расскажу т.к. сам их только изучаю.