А смысл именно в PPC?! Может быть легче купить эвалюэйшин боард с чем нибудь типа моторолы MPC860, как раз на такой лет 5 назад ядро портировал с эзернетом, uboot-ом, гусарами, рулеткой и куртизанками.
Купить борду можно на ебее, и легче и проще и не нужно обходить эпловые загрузчики/защиты.
А вообще-то мир на армы переходит....
Если первый контекст не является финальным, то да, убираем тру/катч и передаем исключение дальше.
И если второй контекст является "финальным", то обрабатываем исключение и/или прерываемся, например этот контекст используется для логирования, то такое поведение нормально. Тем более, если нам захочется его как-то расширить, например передавать код ошибки через вебсервис, то мы легко это сделаем всего лишь в одном месте.
И да, когда-то сам делал инициализацию через NullPointerException :-) , так что понимаю о чем пишу, да удобно, но как-то тормозливо, и как-то не там...
В этом случае (и остальных!!!) выкидывать его на самый верх в бизнеслогику. Я так и предпочитаю, все исключения как раз и должны быть на уровне бизнеслогики., остальное проверяется без исключений. Соответственно, все что можно выкидываем на верх, остальное проверяем.
Пример, открыть файл и если его нет, создать новый. Кажется, вот оно хорошее место для исключений - не ведитесь на это, просто проверьте перед открытием, что файло существует, и если нет, создайте его без исключений.
Тогда и ваш код будет совсем без try/catch, который будут только в самых существенных местах. Иногда, конечно, раздражает кортеж исключений в определении метода, ну так перейдите в этом случае на родителя (на класс выше) и будет щазтие. Ну и это как минимум повод задуматься, почему у меня тут и исключения от базы и от файлов и еще куча всякого... что-то явно не так тут...
Поддержу, супермайкро хороши. Вот только про апгрейдопрогодность я бы сильно не думал, особенно через 5 лет! тогда ни памяти ни процессоров таких не будет, а если и будут, то за те деньги легче новый собрать. И время жизни серверов лет 5 обычно. И что дома делать с зионом я понятия не имею, лучше i7 ограничиться.. А еще лучше взять самую простую мать.
Проблемы? Да их есть куча!!! вот например с мускулом - habrahabr.ru/company/bitrix/blog/146490
Для ростгреса практически все также актуально, как собственно и для оракла сайбейса и всех остальных.
Тем более, что в изначальном вопросе был намек на быстрое добавление новых нод (в том числе, как я понял и баз данных), что в случае с мастер-мастер приведет к лавионобразному росту трафика, блокировакам, рассинхронизации данных и всему остальному хорошему.
Попробуйте для себя разбить задачу на три:
- добавление новых нод
- резервирование данных
- восстановление после сбоя
И мир будет без мастер-мастер репликации.
Мастер-мастер иногда нужна, когда есть приложение, а программистов для него уже нет. Вот тут ничего другого и не остается, увы... Но делать так с самого начала - увольте.
Отказоустойчивости - никак, а про нее в изначальном вопросе ничего и не было сказано. А если про нее говорить, то делайте мастер-слейв репликацию, вот отказоустойчивость и появится. Или для таких случаем держите бакап-базу (две-три если нужно), куда раз в сколько-то сливайте все изменения со всех серверов, и когда шардинг рассыпается, то подключайтесь к ней на чтение. В любом случае политик здесь будет гораздо больше, чем непрерывно лить изменения со всех на все. Или как политика, если какой-то кусок шардинга недоступен, то льем данные в локальную базу, а потом переливаем куда нужно, при этом кусок данных упавшего сервера будет конечно недоступен, а вот критично это или нет - все зависит как построить приложение...
Ну, вот :-( Всё, что не стоит делать, мы и делаем. Забег по граблям объявляем открытым?
PS. Поставьте glusterfs и избавьтесь от репликации и шардируйте базы данных.
И да, это потребует некоторого вмешательства в код (для шардинга), но это на порядок, именно на порядок, лучшее решение, чем городить промежуточный слой с кучей проблем в дальнейшем.
Для этого, если хостинг, файлы не редактирую напрямую на нем! А делают их локально, и только потом заливают отлаженную версию на сервер или хотинг. Какие, собственно, проблемы поднять у себя апач/нгинх/пехапе/мускул?! Я бы руки разработчику оторвал, если бы он у меня правил файлы на рабочем сервере, сначала минус премия, а затем и досвидание..
У! На очень многое способен! Может даже зафаерволенные хосты определять по клиентским сокетам.. Это когда хотс на пинг не отвечает и закрыто почти все...
@Truerz О! Хорошая статья на тему - 0pointer.net/blog/projects/locking.html "File locking on Linux is just broken. The broken semantics of POSIX locking show that the designers of this API apparently never have tried to actually use it in real software. It smells a lot like an interface that kernel people thought makes sense but in reality doesn't when you try to use it from userspace."
Про локи, что будет, если процесс захватил лок на файл и умер, не успев его отдать?! Будет дедлок! Так как другие процессы будут ждать освобождения ресурса и никогда его не получат. Спасают таймауты и разбор полетов с лок-файлом, но это из другой оперы, это велосипед.
@Truerz Ну, а то уже написал, что с файлом вариант не самый лучший в любом случае! Я бы отказался от этой идеи, но решать Вам. @Eddy_Em предложил хороший вариант с mmap, поддерживаю.
Еще как вариант с файлами - делать блокировку не на файле, который переписываем (мувим), а на другом (специально для этого созданном) файле. Ну а если нужна нормальная отказоустойчивость, то разворачивайте что-то типа zookeeper, используйте очереди или отдельный демон. И не изобретайте велосипед, иначе с локами получите дедлок и долго будете с ним бороться!!! Мир прошел через это лет 10 назад!
Лучше сделайте демон и из него почаще - flush на диск.
Ну а если обрисуете задачу поконкретнее, то может быть что и более конкретное предложу(жат).
Купить борду можно на ебее, и легче и проще и не нужно обходить эпловые загрузчики/защиты.
А вообще-то мир на армы переходит....