Ну полноценную музыку мне не нужно конечно же, какую-нибудь базовую полифонию разве. А по поводу меандра и таймера, как они влияют на звук? Как это связано с частотой звука в герцах?
А если сессия отвалится по тайм-ауту или просто сам сервер вызовет ошибку и будет перезагружен. В этом случае пользователь потеряет свои документы. Это тоже не самый удобный вариант
я не уверен как этот параметр называется в mysql, но думаю именно он. А еще проверьте, есть ли там схожий параметр _archive_file_size (туда сливаются данные, когда файл лога переполнен). Рекомендуемые размеры этих файлов лучше спросить у специалистов, которые смогут подсказать, согласно размеру вашей БД.
Сам бекап вам не нужен, а нужно просто сохранить дерево каталогов и файлов? Т.е. примерно тоже самое, что делает консольная команда tree. > c:/tree.txt?
Если не хочется создавать отдельные namespace, то можно попробовать извратиться с view, например для каждого пользователя свои view для всех операций доступа. А на таблицы вешать partitions, чтобы они могли физически располагаться отдельно, что должно увеличить время доступа при наличии нескольких тысяч пользователей и нескольких миллионов записей в самих таблицах
Правильно поняли, смысл примерно такой же. Все необходимые таблицы для каждого пользователя отдельно. Нужны скрипты чтобы автоматически создать копию default namespace для конкретного пользователя.
Участников с ролью MASTER может быть много. Имелось ввиду. что нельзя назначить одновременно несколько ролей одному пользователю (участник может иметь только одну роль)
По своему опыту могу сказать, что одна из самых больших проблем, с которой я встречался — это распределенные транзакции, когда один «запрос» затрагивает сразу несколько сервисов, и в случае краха одного из них необходимо откатить все изменения. Из-за отсутствия поддержки распределенных транзакций нам постоянно приходилось подчищать все вручную. Если будете делать сервисно-ориентированное ПО, то обязательно продумайте, как вы будете фиксировать или откатывать изменения, обязательно применяйте интеграционные тесты на ошибочных данных и проверяйте правильность работы системы.
Для работы с JSON мне больше нравится Google Json Library code.google.com/p/google-gson/ в нем как и по-очередное чтение/запись, так и сразу биндинг на целые объекты и коллекции
Настроить все это самостоятельно конечно же можно, я не отрицаю. Но с постепенным ростом количества интансов, возможно будет не так просто за ними следить (придется писать новые скрипты, проверяющие доступность инстансов, распределять нагрузку между ними более эффективно, проводить статистику), а в облаке уже все необходимые вещи присутствуют.
А иногда и вовсе бывает нужно частное облако. Когда в компании есть служба для работы с отчетами, которые сдаются ежеквартально, и нагрузка в обычное время на них минимальна, а при сдаче квартальной отчетности, возрастает в десятки и сотни раз. В случае облака, можно настроить расширение в пару кликов, в случае дедиков, это придется настраивать самостоятельно, чтобы в случае повышенной нагрузки, поднимались новые дедики, а на них запускались новые инстансы приложений, а по мере снижения нагрузки, имеющиеся ресурсы этих дедиков шли на что-то другое.
Ну и кроме того, когда имеем несколько инстансов приложения, их можно обновлять постепенно один за другим, накладывая критические патчи безопасности на них, не требуя остановки всех инстансов приложения.
EJB, чтобы это работало в кластере и облачных технологиях (распределение нагрузки между серверами) благодаря remote EJB и при этом поддерживалась распределенная транзакция между всеми такими вещами.
