Здравствуйте, Keith, Вы писали:

.>>Мы использовали — работает. Но мы допиливали под наши условия. Идея там правильная для некоторых типов приложений, но надо хорошо продумать что там с чем будет обмениваться, использовать приёмы построения распределённых систем.
K>А можно вкратце как там разруливается синхронизация структуры с циклическими зависимостями?
K>Оно умеет само внутри одной транзакции снимать foreign key'и, заливать данные, восстанавливать foreign key'и?
K>Как происходит разруливание конфликтов при, например, иземнении структуры или основных таблиц типа справочников?
K>Вообще — тема очень интересная, но очень сложная, удивлен, что кто-то написал такую либу для любых структур данных..
K>У микрософта есть Sync, но тот очень громоздкий и примитивный — все на тригерах, структуру обновлять нельзя и если что-то сломается, то хрен починишь.
Оно тоже работает на основе триггеров. Но не громоздкий, и, по-моему, довольно простой. Изменения структуры решается версированием структуры данных.
Все модифицирующие запросы — insert/update/delete — записываются в упорядоченный лог. Потом этот лог отправляется клиентам и они проигрывают ровно те же изменения на тех же данных в ровно том же порядке, и т.к. это всё сработало в одном месте, сработает и в другом. Поэтому никаких сниманий foreign key нет и не надо. Одно надо — хорошо продумать структуру данных, чтобы она была централизована на сервере или создавалась клиентами безконфликтно, возможно придётся вводить какие-то механизмы мержей. Например, если 2 клиента добавили одно и то же значение в справочник, то ID изначально должны быть разные (вообще в качестве ID в распределённых системах должен быть UUID), появится дубликат, но можно сделать механизм схлопывания дубликатов (и этим будет заниматься сервер централизовано, чтобы избежать конфликтов).
Хотя на самом деле когда мы это применяли, у нас изменением данных в БД занимался только сервер, а клиентские БД были read-only, т.е. просто кеш. Но принцип вроде такой же.

.>>Веб-старт в принципе работает... но глючный он какой-то и старый. Можете с него начать, но, думаю, несложно будет перейти на что-то своё.
K>Спасибо за мнение, решил пока с ним разобраться, а дальше буду смотреть...

Здравствуйте, Keith, Вы писали:

K>1. Web-интерфейс, потому что он наиболее rich, кросс-платформенный и под него полно дизайнеров
То есть пользователь это не оператор. Он не вбивает данные в формы в течении 8-ми часового рабочего дня. Так?
K>3. Приложение должно сохранять вводимые специалистом данные в in-process базу и по мере наличия интернета "синхронизироваться" с основной базой.
Синхронизация достаточно сложный процесс. У нас немного другая схема и нам пришлось реализовывать её с нуля. Если к синхронизации много бизнес-требований, то готовые решения потом замучаешься тюнинговать.

K>Написать приложение-сервис, которое хостит в себе веб-севис (Jetty) с сайтом (на Grails) и базу (H2 / Mongo).
Почему NoSQL?
K>Плюс, отдельное update-приложение, которое занимается обновлением сервиса — останавливает сервис, поднимать рядом новую версию сервиса, накатывать на базу миграции, проверяет работоспособность поднятого, удаляет старое и если что — все корректно откатывает и т.д.
Умеют ли вышеуказанные базы откатывать изменения схемы без последствий?

K>1. Сложность написания приложения без ошибок и трудность автоматизации тестирования обновления (время разработки может растянуться на неопределенный срок)
Не очень понял. В приложении буду ошибки всегда. Это можно принять за аксиому. Обновление можно встроить в Continuous Integration. Другого теста ему не нужно.

K>2. В случае бага, падения update-приложения, разрядки батареи ноута и т.д. возможна ситауция, когда работа приложения не будет восстановлена и пользователь не сможет работать с приложением, а это критично для бизнеса, а так же не просто будет выяснить как именно все сломалось и написать приложение для восстанавления работы сломанного приложения.
Вывод. Переключение между версиями должно занимать минимальное время. Всё остальное нужно выносить в фоновый процесс.

K>Вместо сервиса сделать standalone-приложение, которое не только хостит в себе веб-сервер и базу
Это разумно.
K>но и окно в котором хоститься браузер (ui-элемент), который в себе отображает хостящийся сайт.
В этом нет необходимости. Браузер всегда можно стартовать отдельно по определенным событиям.

K>Для обновления использовать Web Start (jnlp). База будет лежать рядом вне jnlp-файла.
K>При обновлении jnlp-приложения (на сколько я понимаю механизм уже хорошо отлажен) и первом запуске обновленного приложения будет проверяться версия базы и если нужно — накатываться миграции.
Не вижу особых преимуществ. Кроме того что не нужно изобретать велосипед с обновлением. Но вопрос отката в случае ошибки обновления схемы остаётся открытым.

K>Тут все выглядит проще и надежнее (для меня):
K>- не нужно писать свой механизм обновления
Да.

K>- не нужно посылать пользователя в браузер по урлу localhost:xxxx — он просто работает с приложением
Это легко автомтизировать.

K>- не нужно писать сервис, который сложнее в администрировании, отладке и обновлении (могут требоваться перезагрузки)
Писать сервис не нужно. Существуют готовые решения. Перезагрузки тоже не нужны. Сервис это просто обертка над Java процессом. Особой разницы нет, кроме той что останавливать\запускать процесс нужно другим способом.

K>- если что-то сломается, можно обновить jnlp файл, он автоматом обновится у пользователя и все заработает как надо (хотя фаза выяснения состояния сломанного приложения на ноуте пользователя все равно есть и может сильно все усложнять).
Оптимистично.

K>2. Какие более простые способы есть написания такого типа приложения? Из ограничений — JVM и open source.
Напишите прототип jnlp, jetty, procrun и выбраная база. И протестируйте на этом прототипе обновления с откатом и ошибками.

Здравствуйте, LeonidV, Вы писали:

K>>Я имел ввиду, что GWT не охота, хотя вариант интересный, учитывая, что GWT-сайт можно собрать в war и захостить где угодно, не завися от гугла.
LV>Google уже фактически бросил GWT. Сейчас его поддержкой активно занимается Vaadin.
LV>http://googlewebtoolkit.blogspot.ru/2012/09/gwt-survey.html
В GWT уже нет смысла, так как JavaScript решения сейчас бурно развиваются и множество из них делают разработку на JavaScript намного вкуснее чем на GWT.

Здравствуйте, GreenTea, Вы писали:

GT>Далее по шедулеру будет чекать новую версию. Если есть, то скачивается архив с сервером и sql сприпт обновления.
Большинство SQL серверов не умеют транзакционно откатывать DDL.

GT>1) делаем копию базы.
Возможность этого шага сильно зависит от размера локальной базы. Ноутбук не тресене целую базу копировать при каждом обновлении?

GT>Мерж базы тоже должен быть таким, чтобы если отпадет интернет база не осталась в неконсистентном состоянии.
Какой ещё мерж? Апдейты накатываются локальными заранее скачаными скриптами.
Синхронизация с сервером что ли? Так её просто нужно транзакционной сделать.

Здравствуйте, ., Вы писали:

.>Все данные хранятся в СУБД, синхронизация данных — берём symmetricds. Должна быть возможность загрузить чистую базу с сервера, если вдруг поломалась клиентская.
Если в синхронизацию вклинится бизнес-логика, то будет много вопросов в том как то или иное сделать в symmetricds.

.>Изменение структуры БД — liquibase/аналоги.
Flyway мне понравился значительно меньше liquibase. Хотя у него есть и свои плюсы.

.>Приложение, если не сильно увесистое, запаковать в один jar-файл — обновлять целиком, при проблемах — использовать предыдущий.
JNLP позволяет выкачивать только diff между версиями.

.>Т.е. все изменения транзакционные — если что-то прервалось, продолжится дальше, либо будет работать старое.
Это на словах хорошо. А если разбить весь процесс по шагам, то будет очень много вопросов так как далеко не все из них с пол пинка делаются транзакционными.

Здравствуйте, Blazkowicz, Вы писали:

.>>Все данные хранятся в СУБД, синхронизация данных — берём symmetricds. Должна быть возможность загрузить чистую базу с сервера, если вдруг поломалась клиентская.
B>Если в синхронизацию вклинится бизнес-логика, то будет много вопросов в том как то или иное сделать в symmetricds.
Так не надо вклинивать, в том-то и дело.

.>>Изменение структуры БД — liquibase/аналоги.
B>Flyway мне понравился значительно меньше liquibase. Хотя у него есть и свои плюсы.
Я liquibase только трогал, вроде ничё так, работает.

.>>Приложение, если не сильно увесистое, запаковать в один jar-файл — обновлять целиком, при проблемах — использовать предыдущий.
B>JNLP позволяет выкачивать только diff между версиями.
Если аппликуха небольшая, то можно не заморачиваться.

.>>Т.е. все изменения транзакционные — если что-то прервалось, продолжится дальше, либо будет работать старое.
B>Это на словах хорошо. А если разбить весь процесс по шагам, то будет очень много вопросов так как далеко не все из них с пол пинка делаются транзакционными.
Согласен, придётся замахнуться на полтора пинка, а в некоторых случаях на π пинков, но, как мне кажется, ничего невозможного нет.

Здравствуйте, ., Вы писали:

B>>Если в синхронизацию вклинится бизнес-логика, то будет много вопросов в том как то или иное сделать в symmetricds.
Кстати. Если не сложно, можешь поделится опытом использования symmetricds? Что получилось клево и быстро, а с чем пришлось повозится?
Какая топология серверов?

.>Так не надо вклинивать, в том-то и дело.
Синхронизация без логики это тупая репликация.
А требований к синхронизации может возникнуть масса:
Это синхронизируем сейчас, а это синхронизируем потом, по какому-то событию.
Здесь конфликт данных в изменениях со стороны сервера, надо отложить, и дать возможность юзеру исправить.
Здесь просто неожиданная ошибка и надо её изолировать от остальной синхронизации.
Какие-то ошибки можно игнорировать, а какие-то должны останавливать весь процесс.
...и т.п.

.>Я liquibase только трогал, вроде ничё так, работает.
Клёвый. Смущает только XML формат. В .sql файлах не надо <> символы эскейпить и IDE умеют в них подсветку делать.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Keith, Вы писали:

K>>1. Web-интерфейс, потому что он наиболее rich, кросс-платформенный и под него полно дизайнеров
B>То есть пользователь это не оператор. Он не вбивает данные в формы в течении 8-ми часового рабочего дня. Так?

Он именно оператор и вбивает данные, но форму для ввода данных на html можно сделать красивую, в отличие от др. способов.

K>>3. Приложение должно сохранять вводимые специалистом данные в in-process базу и по мере наличия интернета "синхронизироваться" с основной базой.
B>Синхронизация достаточно сложный процесс. У нас немного другая схема и нам пришлось реализовывать её с нуля. Если к синхронизации много бизнес-требований, то готовые решения потом замучаешься тюнинговать.

Вот этого я и боюсь, хотя на начальном этапе не так сложно — набор сущностей-справочников и пара сущностей, которые вводит оператор на основе справочников.
Справочники на сервере могут менятся и во время синхронизации это нужно разруливать.

K>>Написать приложение-сервис, которое хостит в себе веб-севис (Jetty) с сайтом (на Grails) и базу (H2 / Mongo).
B>Почему NoSQL?

Это требование не мое, но можно пока и на H2 — оно sql, в отличие от Mongo.

K>>Плюс, отдельное update-приложение, которое занимается обновлением сервиса — останавливает сервис, поднимать рядом новую версию сервиса, накатывать на базу миграции, проверяет работоспособность поднятого, удаляет старое и если что — все корректно откатывает и т.д.
B>Умеют ли вышеуказанные базы откатывать изменения схемы без последствий?

H2 должен умень — он sql и транзакции есть.

K>>1. Сложность написания приложения без ошибок и трудность автоматизации тестирования обновления (время разработки может растянуться на неопределенный срок)
B>Не очень понял.
B>В приложении буду ошибки всегда.

Это точно.

B>Это можно принять за аксиому. Обновление можно встроить в Continuous Integration. Другого теста ему не нужно.

Как это? А если при обновлении у пользователей миграции не накатяться, хотя на моей тестовой базе все будет ок?
Тут речь о том, что механизм апдейтов писать самому — это перебор, т.к. ошибки в нем могут ломать полностью работу пользователей...
Если только рядом новую версию не поднимать, но тут тоже есть проблема — пользователю не нужны две версии, хотя иначе не понятно как сделать надежно.

K>>2. В случае бага, падения update-приложения, разрядки батареи ноута и т.д. возможна ситауция, когда работа приложения не будет восстановлена и пользователь не сможет работать с приложением, а это критично для бизнеса, а так же не просто будет выяснить как именно все сломалось и написать приложение для восстанавления работы сломанного приложения.
B>Вывод. Переключение между версиями должно занимать минимальное время. Всё остальное нужно выносить в фоновый процесс.

Не важно как мало времени будет занимать, важно, что при наличии бага все может сломаться.

K>>Вместо сервиса сделать standalone-приложение, которое не только хостит в себе веб-сервер и базу
B>Это разумно.
K>>но и окно в котором хоститься браузер (ui-элемент), который в себе отображает хостящийся сайт.
B>В этом нет необходимости. Браузер всегда можно стартовать отдельно по определенным событиям.

Пользователю будет не удобно запускать мой процесс, который висит и ничего не делает и идти руками в браузер на localhost:80ХХ/ чтобы там что-то делать.
Ну и строка браузера с браузерной навигацией пользователю не нужны, поэтому я все-таки хочу встроить браузер сюда же.

K>>Для обновления использовать Web Start (jnlp). База будет лежать рядом вне jnlp-файла.
K>>При обновлении jnlp-приложения (на сколько я понимаю механизм уже хорошо отлажен) и первом запуске обновленного приложения будет проверяться версия базы и если нужно — накатываться миграции.
B>Не вижу особых преимуществ. Кроме того что не нужно изобретать велосипед с обновлением. Но вопрос отката в случае ошибки обновления схемы остаётся открытым.

K>>Тут все выглядит проще и надежнее (для меня):
K>>- не нужно писать свой механизм обновления
B>Да.

K>>- не нужно посылать пользователя в браузер по урлу localhost:xxxx — он просто работает с приложением
B>Это легко автомтизировать.

Автоматизировать легко, но это не юзер френдли. Пользователю не нужно знать про то, что после запуска моего приложения (которое ничего не делает) можно пойти по магическому урлу и там работать...

K>>- не нужно писать сервис, который сложнее в администрировании, отладке и обновлении (могут требоваться перезагрузки)
B>Писать сервис не нужно. Существуют готовые решения. Перезагрузки тоже не нужны. Сервис это просто обертка над Java процессом. Особой разницы нет, кроме той что останавливать\запускать процесс нужно другим способом.

Сервисы не мгновенно перезапускаются, в отличие от обычного приложения, плюс бывают всякие проблемы, которые потом по логам нужно искать.
С приложением все равно проще мне кажется.

K>>- если что-то сломается, можно обновить jnlp файл, он автоматом обновится у пользователя и все заработает как надо (хотя фаза выяснения состояния сломанного приложения на ноуте пользователя все равно есть и может сильно все усложнять).
B>Оптимистично.

Согласен, но проще, чем с сервисом.
Плюс можно новую версию выкатывать как отдельное приложение — хочеь пользуйся старым, хочешь — новым.
В принципе с сервисом не на много сложнее, но все же проще.

K>>2. Какие более простые способы есть написания такого типа приложения? Из ограничений — JVM и open source.
B>Напишите прототип jnlp, jetty, procrun и выбраная база. И протестируйте на этом прототипе обновления с откатом и ошибками.

Сейчас как раз пишу прототип. Только про procrun не знал — посмотрю.
В принципе связка JavaXF + Browser (Web View) + Jetty + Grails site + H2 работает, но застрял с правильной сборкой jar'а.
Из IDE все работает, а когда сам jar собираю Jetty молча (без исключений) не стартует и браузер показывает пустую страницу, но это я думаю разберусь...

Здравствуйте, Blazkowicz, Вы писали:

B>>>Если в синхронизацию вклинится бизнес-логика, то будет много вопросов в том как то или иное сделать в symmetricds.
B>Кстати. Если не сложно, можешь поделится опытом использования symmetricds? Что получилось клево и быстро, а с чем пришлось повозится?
B>Какая топология серверов?
У нас было простая архитектура вообщем-то. Сервер psql, клиенты с локальными h2db. Клиенты используют свои БД для тяжелых запросов к данным, но данные read-only. Все изменения отправляются в виде команд на сервер, сервер делает модифицирующие операции, symmetricds собирает триггерами изменения и они потом рассылаются клиентам.
Проблемы были с авторизацией, когда не все изменеия нужно отправлять всем клиентам, а только те, которые данный клиент в данное время имеет право видеть. Но это было тяжело само по себе, из-за сложной модели бизнес-объектов. Приходилось перестраивать структуру данных и вообще жутко хорошо продумывать что где когда.

.>>Так не надо вклинивать, в том-то и дело.
B>Синхронизация без логики это тупая репликация.
B>А требований к синхронизации может возникнуть масса:
B>Это синхронизируем сейчас, а это синхронизируем потом, по какому-то событию.
B>Здесь конфликт данных в изменениях со стороны сервера, надо отложить, и дать возможность юзеру исправить.
B>Здесь просто неожиданная ошибка и надо её изолировать от остальной синхронизации.
B>Какие-то ошибки можно игнорировать, а какие-то должны останавливать весь процесс.
B>...и т.п.
Сама по себе репликация тоже не простая вещь в распределённой системе. Это же не просто пара master-slave СУБД для failover.
Если продумывать по слоям, т.е. реплицировать на уровне БД, а уже в DAO слое всякие бизнес-синхронизирующие заморочки, думаю получится более надёжно и просто. В общем универсального рецепта нет, понятное дело… Надо конкретные требования рассматривать.

.>>Я liquibase только трогал, вроде ничё так, работает.
B>Клёвый. Смущает только XML формат. В .sql файлах не надо <> символы эскейпить и IDE умеют в них подсветку делать.
XML-формат (ксати, для любителей поддерживается так же json и yaml) для описания самого changeset ну и для тривиальных мелких запросиков, а для сложных вещей из xml можно дёрнуть рядом положенный .sql-файл или загрузить данные из .csv-файла.

Здравствуйте, Keith, Вы писали:

K> Он именно оператор и вбивает данные, но форму для ввода данных на html можно сделать красивую, в отличие от др. способов.
Для оператора юзабилити ввода намного важнее рюшечек HTML. Портировать красивый дизайн с HTML на JavaFX — пару дней вместе с дизайнером посидеть. К тому же там CSS имеется.
Поддержка горячих клавишь на JavaScript и табуляция по форме в браузере — продолжительная головная боль. Браузер снандартизирован? Или все нужно поддерживать?

K>Вот этого я и боюсь, хотя на начальном этапе не так сложно — набор сущностей-справочников и пара сущностей, которые вводит оператор на основе справочников.
K>Справочники на сервере могут менятся и во время синхронизации это нужно разруливать.
Нужно use-case с синхронизацией писать и анализировать.

K>H2 должен умень — он sql и транзакции есть.
Ой, ли
https://groups.google.com/forum/#!topic/h2-database/kqaU7wi3_FY
http://www.h2database.com/html/roadmap.html
Есть SQL транзакции. Транзакционный DDL это отдельная тема.

B>>Это можно принять за аксиому. Обновление можно встроить в Continuous Integration. Другого теста ему не нужно.
K>Как это? А если при обновлении у пользователей миграции не накатяться, хотя на моей тестовой базе все будет ок?
Вероятность этого достаточно мала.

K>Тут речь о том, что механизм апдейтов писать самому — это перебор, т.к. ошибки в нем могут ломать полностью работу пользователей...
Верно. Кстати, в liquibase, по-моему можно для каждого апдейта прописывать rollback скрипт, который он накатит в случае ошибки. Не транзакционно, но зато увеличиват надежность.
Проблема только в том что скрипты эти (rollback) писать каждый раз тоже отдельная работа. А нужны они раз в год.

K>Если только рядом новую версию не поднимать, но тут тоже есть проблема — пользователю не нужны две версии, хотя иначе не понятно как сделать надежно.
Если рядом подымать вторую версию базы, то все равно пользователя нужно отправлять в режим ожидания.
К тому же подумайте над тем как держать две версии базы? Копировать польностью?? Или просто бэкапить?

K>Не важно как мало времени будет занимать, важно, что при наличии бага все может сломаться.
Без этого никуда. Бэкапы разве что делать.

K>Пользователю будет не удобно запускать мой процесс, который висит и ничего не делает и идти руками в браузер на localhost:80ХХ/ чтобы там что-то делать.
С сервисом запускать не нужно. Ссылку можно собрать из настроек и открыть с ней браузер.

K>Ну и строка браузера с браузерной навигацией пользователю не нужны, поэтому я все-таки хочу встроить браузер сюда же.
Ну, не знаю.

K>Автоматизировать легко, но это не юзер френдли. Пользователю не нужно знать про то, что после запуска моего приложения (которое ничего не делает) можно пойти по магическому урлу и там работать...
Если приложение — сервис. Оно всегда онлайн. У юзера на десктопе ярлык с URL, который открывает браузер.
Если приложени — standalone, то оно после запуска может открыть браузер по нужному URL. Проблем юзабилити не вижу.

K>Сервисы не мгновенно перезапускаются, в отличие от обычного приложения, плюс бывают всякие проблемы, которые потом по логам нужно искать.
Это какое-то наследние .NET опыта сказывается. У меня никаких проблем с WebSphere CE и Tomcat запущеными как сервис никогда не было. Время перезапуска сервиса точно такое же как и время перезапуска контейнера.

K>С приложением все равно проще мне кажется.
Ну, кроме того что пользователю надо ждать пока не запустится контейнер. А разработчику нужно следить за тем чтобы запуск контейнера не превышал N секунд.
Можно и standalone. Я особой разницы не вижу, кроме времени запуска.

K>Плюс можно новую версию выкатывать как отдельное приложение — хочеь пользуйся старым, хочешь — новым.
Я себе не представляю как это будет реализовано и как пользователь будет решать которую версию ему запустить.

K>В принципе с сервисом не на много сложнее, но все же проще.


K>Сейчас как раз пишу прототип. Только про procrun не знал — посмотрю.
K>В принципе связка JavaXF + Browser (Web View) + Jetty + Grails site + H2 работает, но застрял с правильной сборкой jar'а.
Смысл не в том что эта связка работает\не работает. Смысл в том что нужно на ней проверить процесс обновления.

K>Из IDE все работает, а когда сам jar собираю Jetty молча (без исключений) не стартует и браузер показывает пустую страницу, но это я думаю разберусь...
Значит что-то не так с логированием.

Здравствуйте, Keith, Вы писали:

K>Доступа к ноутбуку пользователя не будет и даже если будет, то админить каждый ноут будет очень накладно по времени, т.к. может быть 100+ пользователей.
100+, конечно, не так много. У нас вот 1500+. Но я все же рекомендую наладить процесс доставки логов, exception-ов и другой информации от клиентских приложений в support.
На одном проекте у нас юзеру вываливает форма, с помощью которой он может отправить скрин, exception и log.
На другом проекте просто все exception-ы отправляем на суппорт email. Дополнительно аттачим snapshot данных. Вот с доставкой логов я как-то проморгал. Приходится пока админов просить. Но нужно было всего пару раз за 4 месяца. Так что не критично.

K>> Он именно оператор и вбивает данные, но форму для ввода данных на html можно сделать красивую, в отличие от др. способов.
B>Для оператора юзабилити ввода намного важнее рюшечек HTML. Портировать красивый дизайн с HTML на JavaFX — пару дней вместе с дизайнером посидеть. К тому же там CSS имеется.

Политика партии делать на вебе.

B>Поддержка горячих клавишь на JavaScript и табуляция по форме в браузере — продолжительная головная боль. Браузер снандартизирован? Или все нужно поддерживать?

Пока считаем, что стандартизован — последний десктопный ИЕ.

K>>Вот этого я и боюсь, хотя на начальном этапе не так сложно — набор сущностей-справочников и пара сущностей, которые вводит оператор на основе справочников.
K>>Справочники на сервере могут менятся и во время синхронизации это нужно разруливать.
B>Нужно use-case с синхронизацией писать и анализировать.

В смысле, обдумывать какие данные могут быть и как они могут ложится/не ложиться и что в каждом случае делать?
Это само собой, пока пытаюсь просто "взлететь со всем этим".

K>>H2 должен умень — он sql и транзакции есть.
B>Ой, ли
B>https://groups.google.com/forum/#!topic/h2-database/kqaU7wi3_FY
B>http://www.h2database.com/html/roadmap.html
B>Есть SQL транзакции. Транзакционный DDL это отдельная тема.

DDL — это create/alter table? Я и не знал, что это отдельная категория запросов, которая может не транзакционно выполняться

B>>>Это можно принять за аксиому. Обновление можно встроить в Continuous Integration. Другого теста ему не нужно.
K>>Как это? А если при обновлении у пользователей миграции не накатяться, хотя на моей тестовой базе все будет ок?
B>Вероятность этого достаточно мала.

На моей правктике случалось, хотя и нечасто.

K>>Если только рядом новую версию не поднимать, но тут тоже есть проблема — пользователю не нужны две версии, хотя иначе не понятно как сделать надежно.
B>Если рядом подымать вторую версию базы, то все равно пользователя нужно отправлять в режим ожидания.
B>К тому же подумайте над тем как держать две версии базы? Копировать польностью?? Или просто бэкапить?

На самом деле их можно полностью разделить и ничего не копировать.
Получится, что у пользователя есть старая версия со старой базой, которая работает и синхронизируется и
есть новая версия с новой чистой базой.
Когда данные в старой версии будут синхронизированы, можно от нее отказатся и перейти полностью на новую,
а если новая версия с багами, то можно старую запустить.
Только одна проблема — пользователю не желательно знать про две версии...
Можно сделать одну точку входа для пользователя (ярлык для запуска, грубо говоря), и при запуске уже спрашивать какую версию он хочет и какую можно удалить, но
это все равно усложняет процесс для пользователя.

K>>Сервисы не мгновенно перезапускаются, в отличие от обычного приложения, плюс бывают всякие проблемы, которые потом по логам нужно искать.
B>Это какое-то наследние .NET опыта сказывается. У меня никаких проблем с WebSphere CE и Tomcat запущеными как сервис никогда не было. Время перезапуска сервиса точно такое же как и время перезапуска контейнера.

Ох ) А я имел счастье админить Jira на своем сервере, которая как раз в сервисе с tomcat'ом крутилась...
Иногда сервис запускался, а tomcat нет и вроде сервис работает, а по урлу 404 — нужно было руками перезапускать сервис.
Обновление этого барахла — вообще отдельная тема, последний раз не осилил даже, хотя это больше на проблемы Atlassian похоже.

K>>Плюс можно новую версию выкатывать как отдельное приложение — хочеь пользуйся старым, хочешь — новым.
B>Я себе не представляю как это будет реализовано и как пользователь будет решать которую версию ему запустить.

С Web Start'ом просто = есть просто две ссылки (два ярлыка), одна запускает новое приложение, другая — старое.

K>>Из IDE все работает, а когда сам jar собираю Jetty молча (без исключений) не стартует и браузер показывает пустую страницу, но это я думаю разберусь...
B>Значит что-то не так с логированием.

Да, как раз логи настраиваю.
Никак не пойму как c executable jar направить весь вывод в файл.
Получается если сделать так:
java -verbose -jar MyJar.jar > output.txt
но все, что я вижу — это сотня строк с Loaded some.jar типа:
[Loaded java.lang.Object from C:\Program Files\Java\jre7\lib\rt.jar]

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Keith, Вы писали:

K>>Доступа к ноутбуку пользователя не будет и даже если будет, то админить каждый ноут будет очень накладно по времени, т.к. может быть 100+ пользователей.
B>100+, конечно, не так много. У нас вот 1500+. Но я все же рекомендую наладить процесс доставки логов, exception-ов и другой информации от клиентских приложений в support.
B>На одном проекте у нас юзеру вываливает форма, с помощью которой он может отправить скрин, exception и log.
B>На другом проекте просто все exception-ы отправляем на суппорт email. Дополнительно аттачим snapshot данных. Вот с доставкой логов я как-то проморгал. Приходится пока админов просить. Но нужно было всего пару раз за 4 месяца. Так что не критично.

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

Здравствуйте, Keith, Вы писали:

K>Пока считаем, что стандартизован — последний десктопный ИЕ.
Нужно посмотреть как JavaFX выбирает браузер, который он использует.

K>В смысле, обдумывать какие данные могут быть и как они могут ложится/не ложиться и что в каждом случае делать?
K>Это само собой, пока пытаюсь просто "взлететь со всем этим".
Ну, вообще потоки данных, поведение юзера. От этого очень много всего зависит. Конфликты там, требования к синхронизации. Мы же не знаем вашего workflow.

K>DDL — это create/alter table? Я и не знал, что это отдельная категория запросов, которая может не транзакционно выполняться :shuffle:
Именно. И она почти везде не транзакционна.

K>На самом деле их можно полностью разделить и ничего не копировать.
K>Получится, что у пользователя есть старая версия со старой базой, которая работает и синхронизируется и
K>есть новая версия с новой чистой базой.
Ну, вот это уже исходя из каких-то требований можно иметь чистую базу. А что делать если каким-то SQL нужно преобразовать данные?

K>Когда данные в старой версии будут синхронизированы, можно от нее отказатся и перейти полностью на новую,
K>а если новая версия с багами, то можно старую запустить.
Дык вопрос о существующих данных. Как они между разными базами будет передаваться? Через бэкап? Через копирование? Или новая версия — всё с чистого листа?

K>Только одна проблема — пользователю не желательно знать про две версии...
Вооот. А потом ты говоришь про два ярлыка на рабочем столе. :))

K>Можно сделать одну точку входа для пользователя (ярлык для запуска, грубо говоря), и при запуске уже спрашивать какую версию он хочет и какую можно удалить, но
K>это все равно усложняет процесс для пользователя.
Пользователь не хочет этого знать и не хочет принимать такого решения. Я бы здесь на него не полагался.
Вообще 100+ юзеров это не много и единичные проблемы вполне может разруливать админ\девелопер. Суппорт ведь нужен в любом случае.


K>Ох ) А я имел счастье админить Jira на своем сервере, которая как раз в сервисе с tomcat'ом крутилась...
K>Иногда сервис запускался, а tomcat нет и вроде сервис работает, а по урлу 404 — нужно было руками перезапускать сервис.
Это не томкат не запускался. А jira апликуха внутри него. Это сугубо вопрос деплоймента и к взаимоотношениям сервис-томкат отношения не имеет.

K>Обновление этого барахла — вообще отдельная тема, последний раз не осилил даже, хотя это больше на проблемы Atlassian похоже.
Мне тоже кажется что к Windows Service это никакого отношения не имеет.

K>С Web Start'ом просто = есть просто две ссылки (два ярлыка), одна запускает новое приложение, другая — старое.
Пользователь будет в шоке.

K>Да, как раз логи настраиваю.
K>Никак не пойму как c executable jar направить весь вывод в файл.
K>Получается если сделать так:
K>java -verbose -jar MyJar.jar > output.txt
K>но все, что я вижу — это сотня строк с Loaded some.jar типа:
K>[Loaded java.lang.Object from C:\Program Files\Java\jre7\lib\rt.jar]
Это уже "добро пожаловать в Java форум". Лучше таки установить логгер, который и system.out в свои логи редиректит.

K>>Когда данные в старой версии будут синхронизированы, можно от нее отказатся и перейти полностью на новую,
K>>а если новая версия с багами, то можно старую запустить.
B>Дык вопрос о существующих данных. Как они между разными базами будет передаваться? Через бэкап? Через копирование? Или новая версия — всё с чистого листа?

Да, можно с чистого листа.
Пользователь в старой версии все синхронизирует и может работать с новой версией. А может со старой, если новая с багами.
Понятно, что могут быть требования перетаскивать данные — в принципе, не вижу проблемы.
Если структура изменилась, то 1. старую базу можно клонировать, 2. накатить на клон миграции и 3. перетащить нужные данные в новую базу.
Транзакций не будет на шаге 1 и 2, но в случае их поломки можно начать с начала, очистив каталог для клона.
На шаге 3 транзакции будут.

K>>Только одна проблема — пользователю не желательно знать про две версии...
B>Вооот. А потом ты говоришь про два ярлыка на рабочем столе.
Да, я фантазирую на тему, т.к. сделать прототип нужно уже сейчас, а требования еще до конца не ясны.
Я пока решил сделать standalone приложение и выложить его с помощью web start'а, а дальше уже по обстоятельствам можно будет что угодно подсунуть при обновлении — хоть сервис.

K>>Можно сделать одну точку входа для пользователя (ярлык для запуска, грубо говоря), и при запуске уже спрашивать какую версию он хочет и какую можно удалить, но
K>>это все равно усложняет процесс для пользователя.
B>Пользователь не хочет этого знать и не хочет принимать такого решения. Я бы здесь на него не полагался.

Согласен.
Учитывая сложность темы обновления, я бы для начала просто миграции накатывал на туже базу и смотрел как много пользователей при этом отваливается и на сколько
это критично. А дальше уже придумывал какие-то страховочные механизмы.

B>Вообще 100+ юзеров это не много и единичные проблемы вполне может разруливать админ\девелопер. Суппорт ведь нужен в любом случае.
Сапорт пока не подразумевается, если только в лице меня ) А мне еще код писать, поэтому лучше бы администрирование сократить до минимума.
Это число ориентировочное и будет в начале, сколько будет потом — неизвестно, может быть и 1000+.

K>>С Web Start'ом просто = есть просто две ссылки (два ярлыка), одна запускает новое приложение, другая — старое.
B>Пользователь будет в шоке.

Да ладно ) Ну ок, другой вариант, ссылка на старое приложение будет прямо в моем приложении, как при изменении сайтов делают (гугл, например).

K>>[Loaded java.lang.Object from C:\Program Files\Java\jre7\lib\rt.jar]
B>Это уже "добро пожаловать в Java форум". Лучше таки установить логгер, который и system.out в свои логи редиректит.
Дело похоже не в логе... Но спасибо за совет, пойду действительно напишу...

Здравствуйте, Blazkowicz, Вы писали:

K>>Да, как раз логи настраиваю.
K>>Никак не пойму как c executable jar направить весь вывод в файл.
K>>Получается если сделать так:
K>>java -verbose -jar MyJar.jar > output.txt
K>>но все, что я вижу — это сотня строк с Loaded some.jar типа:
K>>[Loaded java.lang.Object from C:\Program Files\Java\jre7\lib\rt.jar]
B>Это уже "добро пожаловать в Java форум". Лучше таки установить логгер, который и system.out в свои логи редиректит.

Не могли бы Вы поучавствовать вобсуждении этого вопроса?
http://rsdn.ru/forum/java/5241230.flat#5241230

Автор: Keith
Дата: 24.07.13

Здравствуйте, Keith, Вы писали:

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

Что-что? Без предупреждения и подтверждения пользователя сниферить состояние его рабочей станции? Этого себе даже Корпорация Майкрософт не позволяет.

Здравствуйте, akasoft, Вы писали:

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

A>Что-что? Без предупреждения и подтверждения пользователя сниферить состояние его рабочей станции? Этого себе даже Корпорация Майкрософт не позволяет.

Всегда можно "попросить" (заставить) пользователя поставить галку )

Здравствуйте, akasoft, Вы писали:

A>Что-что? Без предупреждения и подтверждения пользователя сниферить состояние его рабочей станции? Этого себе даже Корпорация Майкрософт не позволяет.
Сейчас этим занимаются все кому не лень. Например, если, проект собственность одной компании и пользователи её работники, то тут вообще нет никаких нарушений.
Но замечание правильно в том смысле что Privacy Policy для каждого проекта могут быть разные.

Здравствуйте, Keith, Вы писали:

K> Всегда можно "попросить" (заставить) пользователя поставить галку )

Какая галка? Тебе в данных исключения поедет приватная информация о бизнес-объекте (ты же хочешь разобраться с природой ошибки и убрать её) через незащищённые каналы (почта), плюс к этому ты захочешь информацию об окружении, вызвавшем ошибку, а это уже почти что персональная информация о пользователе, это его личное дело, что он там за программы запускает.

Молчком собирать информацию и отсылать неправильно. Ведь можно спровоцировать ситуацию, и подменить адрес отправки. И это уже уязвимость в ПО, заложенная при проектировании. А зачем тебе лишние проблемы?