Откладывание проверки до commit — очень плохая практика для последующего переиспользования кода. Сложно будет делать массовые операции или подключать приложения, которые самостоятельно управляют транзакциями (exception в необычном месте).
И слишком громоздко для проверки "единственности" клерка в филиале. Если это просто пример одной проверки, а реальные проверки гораздо сложнее, то сойдет.
Если делаются только проверки, похожие на обычный constraint, то их конечно, лучше реализовывать с помощью constraint'ов. В данном примере — сделав денормализацию поля LOC (филиал) в таблице EMP и добавив проверку уникальности сочетания LOC, IS_CLERK. Плюс этого решения — крайняя простота (и сработает даже в Oracle 9i), минус — проблемы при массовых изменениях DEPT.LOC.
Не автоматизировал, как автор данной статьи. Просто использую программу telnet. Режим передачи — построчный. Вбиваем две строки — с GET и с Host (лучше их набрать в блокноте заранее и скопировать), результат сохраняем. У многих сайтов слишком маленький keep-alive, и через telnet очень трудно успеть отправить запрос вручную :)
Давно использую такой вариант. С моим провайдером работает, но через раз приходит страница с уведомлением о блокировке. Т.е. DPI все же умеет частично склеивать HTTP-пакеты.
Раньше при обновлении и переустановке Linux всегда оставлял /home как есть. Один раз менял железо полностью, но раздел /home перекопировал. Несколько раз переставлял ОС: Red Hat -> Kubuntu -> openSuSE.
За 9 лет накопилось чуть более 1 Гб настроек.
Проблемы возникали всего пару раз при смене дистрибутива. Всегда решались нахождением папки настроек конкретного неработающего приложения и ее сносом.
Это было гораздо проще, чем бекапить и вводить каждый раз все настройки заново.
В пользу этого метода можно добавить, что большинство приложений создают папки настроек с номером версии (.kde3, .kde4), так что конфликта не происходит, а некоторые даже предлагали мигрировать настройки в данном случае.
Ура! Теперь, когда настанет вендекапец, останется бесплатная совместимая ОС (примерно такое почти случилось с Амигой и BeOS), в которой можно будет запускать старые игры и ностальгировать
Для большинства подобных случаев хватит dbms_parallel_execute, который работает под любой версией Oralce. Он достаточно прост и понятен, умеет прерывать и возобновлять процесс.
Если есть координирующий процесс и размер порций работы одинаковый и не слишком большой, то использование dbms_app_info кажется излишним. Главный поток может просто смотреть, сколько выполнено и сколько осталось.
Это настройки не для телефона, а для оператора. Просто настраиваются они в телефоне.
У себя в меню настроек вижу 4 опции переадресации:
Всегда на номер: отключено
Если занято: отключено
При отсутствии ответа: отключено
Если недоступен: +79168920892
У кого такая же проблема, выложите, пожалуйста, свои настройки переадресации вызовов. В Андроиде это находится обычно в меню настройки звонков -> Настройка вызовов -> Переадресация вызова -> Если недоступен
Переведите деньги на кредитный счёт, они списываются с дебитового сразу, а на кредитный попадают только на следующий день.
Это совсем не признак Eventually consistent и отсутствия транзакционнсти, это просто признак того, что деньги списались с одного счета и начислились на другой счет в разных транзакциях.
Причин задержки может быть несколько. Скорее всего, как вы и упомянули, с текущими или карточными счетами работает одно ПО, а с кредитными — другое. И совсем не обязательно эти две системы обмениваются информацией в режиме on-line, а скорее всего только периодически, каждую ночь, например.
Обычно в каждой системе присутствует весь необходимый набор счетов, в данном случае — и текущие, и кредитные. Но не факт, что есть актуальные остатки на всех этих счетах. Есть актуальные остатки по «своим» счетам, за которые «отвечает» данная систеам. А «чужие» счета — «технические», и служат для обеспечения этой самой транзакционности.
Другой вариант — транзакции осуществляются через реальный транзитный счет, который выполняет роль «технического» в приведенном примере. Он реален в том смысле, что отражается в балансе как отдельный счет. В таком случае, на нем даже может быть ненулевой остаток после обмена данными между всеми системами и заркытия опер. дня (End of Day). И банк даже может получить с этого выгоду, например, не платить проценты и на страховать остаток. Хотя здесь уже не уверен, но, думаю, вряд ли банки этим не воспользуются))
Про безопасность тоже никто не забыл: между мобильным устройством и токеном данные передаются зашифрованными по ГОСТ 28147-89, а согласование ключей происходит по VKO ГОСТ 34.10-2001 (RFC 4357). Для активации защищенного канала при форматировании токена генерируется пароль, который будет необходимо ввести однократно при подключении устройства в приложении.
Ну еще есть вариант перевести на мейнфрейм несколько (или кучу) БД Oralce и запускать их под Linux'ом.
И слишком громоздко для проверки "единственности" клерка в филиале. Если это просто пример одной проверки, а реальные проверки гораздо сложнее, то сойдет.
Если делаются только проверки, похожие на обычный constraint, то их конечно, лучше реализовывать с помощью constraint'ов. В данном примере — сделав денормализацию поля LOC (филиал) в таблице EMP и добавив проверку уникальности сочетания LOC, IS_CLERK. Плюс этого решения — крайняя простота (и сработает даже в Oracle 9i), минус — проблемы при массовых изменениях DEPT.LOC.
За 9 лет накопилось чуть более 1 Гб настроек.
Проблемы возникали всего пару раз при смене дистрибутива. Всегда решались нахождением папки настроек конкретного неработающего приложения и ее сносом.
Это было гораздо проще, чем бекапить и вводить каждый раз все настройки заново.
В пользу этого метода можно добавить, что большинство приложений создают папки настроек с номером версии (.kde3, .kde4), так что конфликта не происходит, а некоторые даже предлагали мигрировать настройки в данном случае.
Если есть координирующий процесс и размер порций работы одинаковый и не слишком большой, то использование dbms_app_info кажется излишним. Главный поток может просто смотреть, сколько выполнено и сколько осталось.
Это все используемые для 3G частоты? Т. е. со смартфоном без LTE подключаться к Tele2 не имеет смысла?
У себя в меню настроек вижу 4 опции переадресации:
Всегда на номер: отключено
Если занято: отключено
При отсутствии ответа: отключено
Если недоступен: +79168920892
Последний номер — номер автоответчика Вам звонили www.mts.ru/news/2007-12-21-805998
Соответственно, никакой голосовой почты у меня нет, только «Абонент недоступен».
Поставьте «отключено» или тоже номер +79168920892 на «Если недоступен» и будет вам счастье.
А то паника, МТС снова хочет денег!!11))))
Это совсем не признак Eventually consistent и отсутствия транзакционнсти, это просто признак того, что деньги списались с одного счета и начислились на другой счет в разных транзакциях.
Причин задержки может быть несколько. Скорее всего, как вы и упомянули, с текущими или карточными счетами работает одно ПО, а с кредитными — другое. И совсем не обязательно эти две системы обмениваются информацией в режиме on-line, а скорее всего только периодически, каждую ночь, например.
Обычно в каждой системе присутствует весь необходимый набор счетов, в данном случае — и текущие, и кредитные. Но не факт, что есть актуальные остатки на всех этих счетах. Есть актуальные остатки по «своим» счетам, за которые «отвечает» данная систеам. А «чужие» счета — «технические», и служат для обеспечения этой самой транзакционности.
Другой вариант — транзакции осуществляются через реальный транзитный счет, который выполняет роль «технического» в приведенном примере. Он реален в том смысле, что отражается в балансе как отдельный счет. В таком случае, на нем даже может быть ненулевой остаток после обмена данными между всеми системами и заркытия опер. дня (End of Day). И банк даже может получить с этого выгоду, например, не платить проценты и на страховать остаток. Хотя здесь уже не уверен, но, думаю, вряд ли банки этим не воспользуются))
То есть пароль сохраняется где-то на телефоне?