Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>И что ты собираешься в блоке catch писать? IT>>Показывать бабе Мане что произошло.
ГВ>Это-то понятно, а с приложением что ты делать собираешься?
А это уже бабе Мане решать.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
IT>>Ты же говорил, что у тебя в один момент с этим документом только один клиент работает. Какие тогда могут быть проблемы с актуальностью.
AVK>А сам документ может данные тягать из других документов.
А эти документы кто-то редактирует в данный момент?
AVK>Ну если тебе не страшно тогда собственно дальше говорить не о чем. У меня подходы другие. Доверять управление транзакциями клиенту для меня неприемлемо.
Боюсь что ты путаешь тёплое с мягким.
IT>>Да ну? Может всё совсем наоборот? Наверняка ты в таймлайфах теперь большой эксперт Как ты интересно своему объекту жизнь продлеваешь? Или он у тебя на сервере висит пока сервер не перегрузят?
AVK>При чем тут таймлайф? Вероятность сбоя любого из клиентов значительно выше вероятности сбоя единственного сервера.
Хорошо. Вот сбойнул у тебя клиент, что будет с объектом на сервере?
AVK>>>Я тебе пример привел — рассчет больничного. При расчете необходим как сам больничный так и вся зарплата сотрудника за несколько месяцев. Что — считаем на клиенте? Или на сервере? И в том и в другом случае получаем оверхед на перекачку состояний.
IT>>Зависит от задачки
AVK>Ты читаешь внимательно? Задача — рассчет больничного.
... и от того как её решать.
IT>>(можно я немножко попользуюсь этой твоей фразой) Можно считать и на клиенте.
AVK>Т.е. БЛ на клиенте? Ну в общем дальше я обсуждать не хочу, поскольку, как я уже говорил, это для меня неприемлемо в принципе.
По всей видимости уже просто поздно. Если ты зашил алгоритмы расчёта больничного в БЛ на сервере, то я тебе сочувствую.
AVK>Но даже если так — тащить зарплату за несколько месяцев на клиента не лучший способ обеспечить масштабируемость.
Не лучший способ — это переписывать сервер приложений под каждое изменение законодательства.
AVK>Можно, но мне что то не хочется. Я вот все о наших баранах, о том что стейтлес не всегда лучшее решение.
Для твоей задачки оно вполне приемлемо.
AVK>Твоему заказчику не надо. Я тебе об этом постоянно твержу. Не надо только на основании своих конкретных задач делать далеко идущие обобщения.
Обобщения чего? Того что stateless для подавляющего числа задач лучше? Так это и ёжику понятно. Вот только ты один упёрся и не хочешь этого признать.
IT>>Возможно я действительно поотстал от жизни и почему-то думал, что время таких задач уже давно прошло, всё уже понаписано.
AVK>Как можно написать то что еще не придумано? Если бы у нас приняли законодательство один раз и навсегда все бы было хорошо. А на практике постоянно приходится латать и перелатывать.
Почему-то у нас это раньше получалось без постоянного переписыания приложений
IT>>Только то, как ты это делаешь — это конечно же нонсенс. Ты бы ещё предложил редактировать Excel файл, расположенный в памяти апп-сервере.
AVK>Давай не будем передергивать.
А я не передёргиваю. Я тебе просто пытаюсь объяснить, что ты решаешь задачу неверным способом.
IT>> Любой стэйтфул не надёжен по определению, т.к. память пока является самым ненадёжным хранилищем данных.
AVK>Так батенька даже sql-сервер данные хранит в том числе и в памяти. Вот только память на сервере куда надежнее памяти на клиенте.
В памяти он их кэширует. А хранит он их на диске. Чувствуешь разницу?
IT>> Любой идиот понимает, что пока он не нажал Save и не получил ответ OK, данные ещё не сохранены. В общем-то так и делается в stateless.
AVK>Точно так же и в стейтфул.
В твоём stateful пользователь получит подтверждение что всё OK, но гарантии что это так совсем нет. Рассказы о надёжности памяти сервера — это всё ерунда. Не память так каналы связи, не связь так ещё что-нибудь. Надёжный источник только один — жёсткий диск.
IT>>Ты же явно перемудрил. То что ты называешь длинными транзакциями на самом деле называется режимом Undo/Redo.
AVK>Ага, со вложенностью, многоуровневый, версионный и с автоматическим откатом только. А так да, обычный Undo/Redo
О! Начинаешь соображать
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
ГВ>>>>И что ты собираешься в блоке catch писать? IT>>>Показывать бабе Мане что произошло. ГВ>>Это-то понятно, а с приложением что ты делать собираешься?
IT>А это уже бабе Мане решать.
Смешно. Уже вижу бабу Маню с дебуггером в руках. Но я не об этом спрашивал. Хорошо, поставим вопрос по-другому. Что баба Маня сможет сделать? Ну, из каких вариантов будет у неё выбор? И как будет клиент (и/или сервер) обрабатывать выборы бабы Мани?
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
IT>>>Ты же говорил, что у тебя в один момент с этим документом только один клиент работает. Какие тогда могут быть проблемы с актуальностью. AVK>>А сам документ может данные тягать из других документов. IT>А эти документы кто-то редактирует в данный момент?
А почему бы и нет? Если объекты "живут" на App-сервере, то такая задача вполне решаема (если сие нужно, конечно).
[...]
IT>>>Да ну? Может всё совсем наоборот? Наверняка ты в таймлайфах теперь большой эксперт Как ты интересно своему объекту жизнь продлеваешь? Или он у тебя на сервере висит пока сервер не перегрузят? AVK>>При чем тут таймлайф? Вероятность сбоя любого из клиентов значительно выше вероятности сбоя единственного сервера. IT>Хорошо. Вот сбойнул у тебя клиент, что будет с объектом на сервере?
Провисит себе объект до следующего соединения этого же клиента и всё — продолжит клиент юзер с того места, на котором его застигла стихия. Ну, или будет убран по истечении таймаута с откатом транзакции. Вариантов — вагон.
[...]
IT>>>(можно я немножко попользуюсь этой твоей фразой) Можно считать и на клиенте. AVK>>Т.е. БЛ на клиенте? Ну в общем дальше я обсуждать не хочу, поскольку, как я уже говорил, это для меня неприемлемо в принципе. IT>По всей видимости уже просто поздно. Если ты зашил алгоритмы расчёта больничного в БЛ на сервере, то я тебе сочувствую.
Странно. Если зашивать БЛ в хранимых процедурах, то это хорошо, если в в промежуточном слое — плохо, а если на клиенте, то опять хорошо. О, загадочная русская душа!
AVK>>Но даже если так — тащить зарплату за несколько месяцев на клиента не лучший способ обеспечить масштабируемость. IT>Не лучший способ — это переписывать сервер приложений под каждое изменение законодательства.
Правильно, его лучше написать один раз. А кто говорил, что App-сервер переписывается? Переписывается БЛ. Кстати, это не отрицает того, о чём я тебе раньше говорил, что база данных по имени "App-сервер" есть специально спроектированная под задачу база данных. Просто нужно разделять две вещи: Ядро App-сервера и App-сервер, как совокупность БЛ и ядра, только и всего.
AVK>>Можно, но мне что то не хочется. Я вот все о наших баранах, о том что стейтлес не всегда лучшее решение. IT>Для твоей задачки оно вполне приемлемо.
Хммм... задачка-то вполне неплохо иллюстрирует плюсы и минусы обоих подходов.
AVK>>Твоему заказчику не надо. Я тебе об этом постоянно твержу. Не надо только на основании своих конкретных задач делать далеко идущие обобщения. IT>Обобщения чего? Того что stateless для подавляющего числа задач лучше? Так это и ёжику понятно.
Покажите мне того ёжика!
IT> Вот только ты один упёрся и не хочешь этого признать.
Не один. Что за намёки?
IT>>>Возможно я действительно поотстал от жизни и почему-то думал, что время таких задач уже давно прошло, всё уже понаписано. AVK>>Как можно написать то что еще не придумано? Если бы у нас приняли законодательство один раз и навсегда все бы было хорошо. А на практике постоянно приходится латать и перелатывать. IT>Почему-то у нас это раньше получалось без постоянного переписыания приложений
Почему-то для stateful получается то же самое, что и для stateless — нужно отдеплоить новые модули, если не удаётся просто сконфигурировать старые в соответствии с новым законодательством.
IT>>>Только то, как ты это делаешь — это конечно же нонсенс. Ты бы ещё предложил редактировать Excel файл, расположенный в памяти апп-сервере. AVK>>Давай не будем передергивать. IT>А я не передёргиваю. Я тебе просто пытаюсь объяснить, что ты решаешь задачу неверным способом.
Как интересно. Такой темы ещё не поднималось. Уже появились единственно верные способы решения? Я то всегда думал, что здесь есть только приемлемые или неприемлемые способы.
[...]
IT>>> Любой идиот понимает, что пока он не нажал Save и не получил ответ OK, данные ещё не сохранены. В общем-то так и делается в stateless. AVK>>Точно так же и в стейтфул. IT>В твоём stateful пользователь получит подтверждение что всё OK, но гарантии что это так совсем нет. Рассказы о надёжности памяти сервера — это всё ерунда. Не память так каналы связи, не связь так ещё что-нибудь. Надёжный источник только один — жёсткий диск.
Игорь, тема с откложенными транзакциями поднималась в контексте разговора об оптимизациях. Вовсе не обязательно откладывать абсолютно все транзакции. Т.е., отклик "OK", полученный со stateful-сервера вполне себе может для данного конкретного приложения обычно означать, что получено такое же подтверждение от SQL-сервера и транзакция зафиксирована в долговременном хранилище.
Собственно говоря, это пользователя совсем не касается, а касается только и исключительно разработчиков системы. Юзер должен знать, что пока он не нажал на Save ему не желательно выключать свой компьютер, а после Save он уже может выключить свою машину (пролить на неё кофе, переустановить Windows...), включить заново и снова загрузить то, чему он сделал Save. Откуда придёт появится документ — из кэша App-сервера, с диска SQL-сервера и прочее — не имеет никакого значения.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Игорь, тема с откложенными транзакциями поднималась в контексте разговора об оптимизациях. Вовсе не обязательно откладывать абсолютно все транзакции.
И там же говорилось, что нельзя отложить часть транзакций, потому как ни кто не может дать гарантии, что на данных внесенных отложенными транзакциями никто не начнет вносить изменений, которые отложить нельзя.
ГВ>Т.е., отклик "OK", полученный со stateful-сервера вполне себе может для данного конкретного приложения обычно означать, что получено такое же подтверждение от SQL-сервера и транзакция зафиксирована в долговременном хранилище.
Вот это вот и есть промашка в дизайне.
ГВ>Собственно говоря, это пользователя совсем не касается, а касается только и исключительно разработчиков системы.
Тут еще есть один немаловажный момент.
Пока у тебя есть фиксация транзакции в памяти, то заказчик может только держать свечку УПС'у и молиться за всех электриков в округе. Но как только транзакция зафиксировалась на диске, то тут уже он сам в ответе за сохранность данных, он можт отмиррорить этот диск куда угодно, совершенно стандартными средствами, не зависящими от твоего приложения, и головой не болеть.
Здравствуйте, Геннадий Васильев, Вы писали:
IT>>Хорошо. Вот сбойнул у тебя клиент, что будет с объектом на сервере?
ГВ>Провисит себе объект до следующего соединения этого же клиента и всё — продолжит клиент юзер с того места, на котором его застигла стихия.
А как ты клиента идентифицируешь? По логину? Т.е. ты собираешься гонять это каждый раз по сети?
ГВ>Ну, или будет убран по истечении таймаута с откатом транзакции. Вариантов — вагон.
А какой должен быть таймаут? Вдруг баба Маня решила доделать работу после обеда или вообще завтра, а завтра опа, баба Маня, вся твоя работа expired.
IT>>По всей видимости уже просто поздно. Если ты зашил алгоритмы расчёта больничного в БЛ на сервере, то я тебе сочувствую.
ГВ>Странно. Если зашивать БЛ в хранимых процедурах, то это хорошо, если в в промежуточном слое — плохо, а если на клиенте, то опять хорошо. О, загадочная русская душа!
Во первых про SP это твои фантазии, я такого нигде не говорил. Во-вторых, БЛ о которой идёт речь настолько часто меняется, что должна сама быть имплементирована как часть данных системы. В этом случае куда её подгрузить и где выполнить нет никакой разницы.
IT>> Вот только ты один упёрся и не хочешь этого признать.
ГВ>Не один. Что за намёки?
Да-да, простите, двое вас
IT>>Почему-то у нас это раньше получалось без постоянного переписыания приложений
ГВ>Почему-то для stateful получается то же самое, что и для stateless — нужно отдеплоить новые модули, если не удаётся просто сконфигурировать старые в соответствии с новым законодательством.
Мда, оригинально.
IT>>В твоём stateful пользователь получит подтверждение что всё OK, но гарантии что это так совсем нет. Рассказы о надёжности памяти сервера — это всё ерунда. Не память так каналы связи, не связь так ещё что-нибудь. Надёжный источник только один — жёсткий диск.
ГВ>Игорь, тема с откложенными транзакциями поднималась в контексте разговора об оптимизациях.
Не твои ли слова?
Состояния можно сбрасывать, а можно и не сбрасывать. Просто если мы реализуем stateful-модель в памяти App-сервера, то фиксация промежуточных состояний механизмами долговременного хранения информации — порой полезная, но в целом совсем не обязательная фича.
ГВ>Вовсе не обязательно откладывать абсолютно все транзакции. Т.е., отклик "OK", полученный со stateful-сервера вполне себе может для данного конкретного приложения обычно означать, что получено такое же подтверждение от SQL-сервера и транзакция зафиксирована в долговременном хранилище.
Обязательно не откладывать ни одной.
ГВ>Собственно говоря, это пользователя совсем не касается, а касается только и исключительно разработчиков системы. Юзер должен знать, что пока он не нажал на Save ему не желательно выключать свой компьютер, а после Save он уже может выключить свою машину (пролить на неё кофе, переустановить Windows...), включить заново и снова загрузить то, чему он сделал Save. Откуда придёт появится документ — из кэша App-сервера, с диска SQL-сервера и прочее — не имеет никакого значения.
Из кэша или сервера без разницы. Но ты говоришь не о кэше, а о хранилище в памяти апп-сервера, а это большая разница.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Геннадий Васильев, Вы писали:
IT>>А это уже бабе Мане решать.
ГВ>Смешно. Уже вижу бабу Маню с дебуггером в руках. Но я не об этом спрашивал. Хорошо, поставим вопрос по-другому. Что баба Маня сможет сделать? Ну, из каких вариантов будет у неё выбор? И как будет клиент (и/или сервер) обрабатывать выборы бабы Мани?
Расскажи мне о каких хитрых ситуациях шла речь, я тебе скажу что должна делать баба Маня.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
AVK>>А сам документ может данные тягать из других документов.
IT>А эти документы кто-то редактирует в данный момент?
Зависит от задачи
AVK>>Ну если тебе не страшно тогда собственно дальше говорить не о чем. У меня подходы другие. Доверять управление транзакциями клиенту для меня неприемлемо.
IT>Боюсь что ты путаешь тёплое с мягким.
Боюсь нет.
AVK>>При чем тут таймлайф? Вероятность сбоя любого из клиентов значительно выше вероятности сбоя единственного сервера.
IT>Хорошо. Вот сбойнул у тебя клиент, что будет с объектом на сервере?
Либо сработают проверки, если клиент погонит пургу, либо все откатится.
IT>>>(можно я немножко попользуюсь этой твоей фразой) Можно считать и на клиенте.
AVK>>Т.е. БЛ на клиенте? Ну в общем дальше я обсуждать не хочу, поскольку, как я уже говорил, это для меня неприемлемо в принципе.
IT>По всей видимости уже просто поздно. Если ты зашил алгоритмы расчёта больничного в БЛ на сервере, то я тебе сочувствую.
Ты похоже чего то недопонял. Я вобще не пишу БЛ, в принципе. БЛ будут писать совсем другие люди, совсем другой кыалификации. Писать каждый раз на коленке ручками весь сервер это, извини, кустарщина.
AVK>>Но даже если так — тащить зарплату за несколько месяцев на клиента не лучший способ обеспечить масштабируемость.
IT>Не лучший способ — это переписывать сервер приложений под каждое изменение законодательства.
А его никто и не переписывает, переписывают БЛ.
AVK>>Можно, но мне что то не хочется. Я вот все о наших баранах, о том что стейтлес не всегда лучшее решение.
IT>Для твоей задачки оно вполне приемлемо.
Какой? Для зарплаты? IT, ты точно меня не понимаешь. Если бы у меня стояла задача написать зарплату то никто бы с трехзвенкой и не заморачивался бы. Задача стоит написать платформу для решения типовых проблем автоматизации малых и средних предприятий малыми силами.
AVK>>Твоему заказчику не надо. Я тебе об этом постоянно твержу. Не надо только на основании своих конкретных задач делать далеко идущие обобщения.
IT>Обобщения чего? Того что stateless для подавляющего числа задач лучше?
Именно, потому что для подавляющего большинства ТВОИХ задач.
IT>Так это и ёжику понятно. Вот только ты один упёрся и не хочешь этого признать.
Ну во-первых не один, во-вторых ты уперся точно так же и точно так же не желаешь признавать что задачки однюдь не ограничиваются тем что делаешь ты.
AVK>>Как можно написать то что еще не придумано? Если бы у нас приняли законодательство один раз и навсегда все бы было хорошо. А на практике постоянно приходится латать и перелатывать.
IT>Почему-то у нас это раньше получалось без постоянного переписыания приложений
А вы много времени поддержкой занимались? Ты вроде говорил что ваша контора тогдашняя развалилась? Все так и было, есть, и, боюсь, будет в ближайшем будущем.
AVK>>Так батенька даже sql-сервер данные хранит в том числе и в памяти. Вот только память на сервере куда надежнее памяти на клиенте.
IT>В памяти он их кэширует. А хранит он их на диске. Чувствуешь разницу?
Вот и сервер приложений в памяти кеширует, а хранит в БД, чувствуешь разницу?
IT>>> Любой идиот понимает, что пока он не нажал Save и не получил ответ OK, данные ещё не сохранены. В общем-то так и делается в stateless.
AVK>>Точно так же и в стейтфул.
IT>В твоём stateful пользователь получит подтверждение что всё OK, но гарантии что это так совсем нет.
С чего ты взял? Подтверждение он получит только когда пройдет успешный коммит транзакции, а это возможно только при успешной записи в БД.
IT> Рассказы о надёжности памяти сервера — это всё ерунда. Не память так каналы связи, не связь так ещё что-нибудь. Надёжный источник только один — жёсткий диск.
Здравствуйте, Merle, Вы писали:
ГВ>>Игорь, тема с откложенными транзакциями поднималась в контексте разговора об оптимизациях. Вовсе не обязательно откладывать абсолютно все транзакции. M>И там же говорилось, что нельзя отложить часть транзакций, потому как ни кто не может дать гарантии, что на данных внесенных отложенными транзакциями никто не начнет вносить изменений, которые отложить нельзя.
я на эту посылку отвечать не стал. На самом же деле ложки и здесь тоже нет. Если идёт транзакция, которую задерживать нельзя и которая опирается на данные задержанной транзакции, то тогда фиксируется и то, что было отложено. Сие есть простейший выход из ситуации.
ГВ>>Т.е., отклик "OK", полученный со stateful-сервера вполне себе может для данного конкретного приложения обычно означать, что получено такое же подтверждение от SQL-сервера и транзакция зафиксирована в долговременном хранилище. M>Вот это вот и есть промашка в дизайне.
Почему? Я получаю отклик "OK" от App-сервера, который в данный момент (данной конфигурации и т.п.) не использует отложенных транзакций, ergo данные занесены на диск SQL-сервера. В чём промашка?
ГВ>>Собственно говоря, это пользователя совсем не касается, а касается только и исключительно разработчиков системы. M>Тут еще есть один немаловажный момент. M>Пока у тебя есть фиксация транзакции в памяти, то заказчик может только держать свечку УПС'у и молиться за всех электриков в округе. Но как только транзакция зафиксировалась на диске, то тут уже он сам в ответе за сохранность данных, он можт отмиррорить этот диск куда угодно, совершенно стандартными средствами, не зависящими от твоего приложения, и головой не болеть.
Ничего, подержит. Или, глядишь, и головой подумает. Ему по-любому над чем-нибудь, да надо будет "свечку держать": либо над UPS либо над винтами. На всякий случай, ещё раз повторяю: откладывание транзакций — необязательно используемая возможность.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
IT>>>Хорошо. Вот сбойнул у тебя клиент, что будет с объектом на сервере? ГВ>>Провисит себе объект до следующего соединения этого же клиента и всё — продолжит клиент юзер с того места, на котором его застигла стихия. IT>А как ты клиента идентифицируешь? По логину? Т.е. ты собираешься гонять это каждый раз по сети?
Не только по логину. Ещё и SessionID есть. Кстати, а сколько раз аналогичная информация из cookie или Session-storage кататься будет?
ГВ>>Ну, или будет убран по истечении таймаута с откатом транзакции. Вариантов — вагон. IT>А какой должен быть таймаут? Вдруг баба Маня решила доделать работу после обеда или вообще завтра, а завтра опа, баба Маня, вся твоя работа expired.
Да нет, не обязательно. Штатное сохранение промежуточного состояния и всё (в памяти App-сервера это может и неделю проваляться при обеспеченном режиме работы 24x7). Но, в принципе ты прав — если баба Маня просто бросила клавиатуру и пошла пить чай на полдня, то данные могут потеряться, если такая ситуация не учтена в App-ядре системы.
IT>>>По всей видимости уже просто поздно. Если ты зашил алгоритмы расчёта больничного в БЛ на сервере, то я тебе сочувствую. ГВ>>Странно. Если зашивать БЛ в хранимых процедурах, то это хорошо, если в в промежуточном слое — плохо, а если на клиенте, то опять хорошо. О, загадочная русская душа! IT>Во первых про SP это твои фантазии, я такого нигде не говорил. Во-вторых, БЛ о которой идёт речь настолько часто меняется, что должна сама быть имплементирована как часть данных системы. В этом случае куда её подгрузить и где выполнить нет никакой разницы.
Ну хорошо, хорошо, ответ — ниже.
IT>>>Почему-то у нас это раньше получалось без постоянного переписыания приложений ГВ>>Почему-то для stateful получается то же самое, что и для stateless — нужно отдеплоить новые модули, если не удаётся просто сконфигурировать старые в соответствии с новым законодательством. IT>Мда, оригинально.
Ну, наверное, я туп до безобразия, что другого выхода не вижу. ИМХО, если нельзя учесть очередной вираж законодательства ОДНИМ ТОЛЬКО обновлением конфигурационных данных в БД (частный случай хранения конфигурации), то надо переписать часть БЛ и передеплоить оную.
IT>>>В твоём stateful пользователь получит подтверждение что всё OK, но гарантии что это так совсем нет. Рассказы о надёжности памяти сервера — это всё ерунда. Не память так каналы связи, не связь так ещё что-нибудь. Надёжный источник только один — жёсткий диск. ГВ>>Игорь, тема с откложенными транзакциями поднималась в контексте разговора об оптимизациях. IT>Не твои ли слова?
IT>
IT>Состояния можно сбрасывать, а можно и не сбрасывать. Просто если мы реализуем stateful-модель в памяти App-сервера, то фиксация промежуточных состояний механизмами долговременного хранения информации — порой полезная, но в целом совсем не обязательная фича.
Вот реплика, на которую я отвечал:
>> AVK>>Та же бяка в случае тяжелых и сложных алгоритмов, особенно если они распределенные, правда в этом случае хотя бы от клиента не зависим.
>> IT>С ними всегда бяка.
>> Тем не менее в стейтфул модели бяка поменьше.
TK>TK>А если это long running транзакция? Наобходимось сброса состояния на каждом шаге — для statefull это выглядит достаточно странно.
Перефразирую свой ответ. Если не уверен в памяти App-сервера и UPS — сбрасывай состояния по каждому чиху, если уверен — не сбрасывай. С точки зрения прикладного кода это абсолютно монопенисуально, поскольку обрабатывается исключительно ядром App-сервера.
ГВ>>Вовсе не обязательно откладывать абсолютно все транзакции. Т.е., отклик "OK", полученный со stateful-сервера вполне себе может для данного конкретного приложения обычно означать, что получено такое же подтверждение от SQL-сервера и транзакция зафиксирована в долговременном хранилище. IT>Обязательно не откладывать ни одной.
Обязательно обеспечить ACID (мы обсуждаем конкретно — D) на уровне системы, т.е., для её пользователей. А уж как там она обеспечивается — не их дело.
ГВ>>Собственно говоря, это пользователя совсем не касается, а касается только и исключительно разработчиков системы. Юзер должен знать, что пока он не нажал на Save ему не желательно выключать свой компьютер, а после Save он уже может выключить свою машину (пролить на неё кофе, переустановить Windows...), включить заново и снова загрузить то, чему он сделал Save. Откуда придёт появится документ — из кэша App-сервера, с диска SQL-сервера и прочее — не имеет никакого значения. IT>Из кэша или сервера без разницы. Но ты говоришь не о кэше, а о хранилище в памяти апп-сервера, а это большая разница.
Да, извини, оговорился. Выдленный фрагмент следует читать как "из памяти промежуточных состояний App-сервера".
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
IT>>>А это уже бабе Мане решать. ГВ>>Смешно. Уже вижу бабу Маню с дебуггером в руках. Но я не об этом спрашивал. Хорошо, поставим вопрос по-другому. Что баба Маня сможет сделать? Ну, из каких вариантов будет у неё выбор? И как будет клиент (и/или сервер) обрабатывать выборы бабы Мани? IT>Расскажи мне о каких хитрых ситуациях шла речь, я тебе скажу что должна делать баба Маня.
Один из документов, откуда вытягиваются данные для этой транзакции, оказался удалён в промежутке между подкачкой его в кэш клиента и завершением транзакции.
То есть, имеем следующее:
Для ввода и обсчёта документа A используется несколько документов B: b1, b2, b3. Начинаем вводить новый документ a1, для которого подкачиваем на клиента информацию из b1, b2, b3. К моменту нажатия на <Commit> оказывается, что b2 уже успела удалить баба Дуся.
Внимание, вопросы: Как поведёт себя система? Что произойдёт на клиенте? Что сможет сделать баба Маня?
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ> Сие есть простейший выход из ситуации.
Одно непонятно, зачем в нее вообще входить?
ГВ>Я получаю отклик "OK" от App-сервера, который в данный момент (данной конфигурации и т.п.) не использует отложенных транзакций, ergo данные занесены на диск SQL-сервера. В чём промашка?
В том, что написана гора кода, для обеспечения функциональности, которая и так есть в БД.
ГВ>Ему по-любому над чем-нибудь, да надо будет "свечку держать": либо над UPS либо над винтами.
Над винтами держать не обязательно, он может и мирроринг настроить, хоть на десять дисков, и данные сливать хоть в другую страну, в полном онлайне, совершенно стандартными средствами.
ГВ> На всякий случай, ещё раз повторяю: откладывание транзакций — необязательно используемая возможность.
Да зачем ее вообще вводить?
Здравствуйте, Merle, Вы писали:
ГВ>> Сие есть простейший выход из ситуации. M>Одно непонятно, зачем в нее вообще входить?
Ну не включай отложенные транзакции.
ГВ>>Я получаю отклик "OK" от App-сервера, который в данный момент (данной конфигурации и т.п.) не использует отложенных транзакций, ergo данные занесены на диск SQL-сервера. В чём промашка? M>В том, что написана гора кода, для обеспечения функциональности, которая и так есть в БД.
Ещё раз, медленно. Отложенные транзакции являются следствием stateful-модели, используемой для реализации бизнес-логики. Обеспечением необходимой функциональности занимается App-ядро, которое вообще-то пишется совсем не ради отложенных транзакций, а ради однократной и реюзабельной реализации ряда возможностей, в том числе — объектно-ориентированного программированиябизнес-логики (см. Object-Relational Mapping, например).
ГВ>>Ему по-любому над чем-нибудь, да надо будет "свечку держать": либо над UPS либо над винтами. M>Над винтами держать не обязательно, он может и мирроринг настроить, хоть на десять дисков, и данные сливать хоть в другую страну, в полном онлайне, совершенно стандартными средствами.
Ну-ну, попробуй не "держать свечку над винтами"...
ГВ>> На всякий случай, ещё раз повторяю: откладывание транзакций — необязательно используемая возможность. M>Да зачем ее вообще вводить?
Причины всё те же самые: скорость исполнения и удобство программирования в ряде случаев. Всё на поверхности. И десять раз тут уже поминалось.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ещё раз, медленно. Отложенные транзакции являются следствием stateful-модели, используемой для реализации бизнес-логики.
Да ну? А значит без отложенных транзакций — это уже не stateful?
ГВ>Обеспечением необходимой функциональности занимается App-ядро, которое вообще-то пишется совсем не ради отложенных транзакций, а ради однократной и реюзабельной реализации ряда возможностей, в том числе — объектно-ориентированного программированиябизнес-логики (см. Object-Relational Mapping, например).
И которое с тем же успехом может быть написано и в stateless модели. Ровно с тем же самым ORM.
С другой стороны, опять-таки можно реализовать тот же самый stateful и без отложенных транзакций.
Нафига они вообще нужны ты так и не объяснил.
ГВ>Причины всё те же самые: скорость исполнения и удобство программирования в ряде случаев.
Выигрыш в скорости если и есть, то совсем мизерный. Удобства тоже никакого, скорее привычка.
Здравствуйте, Merle, Вы писали:
ГВ>>Ещё раз, медленно. Отложенные транзакции являются следствием stateful-модели, используемой для реализации бизнес-логики. M>Да ну? А значит без отложенных транзакций — это уже не stateful?
Нет, stateful может быть и без отложенных транзакций, просто они очень естественно в этой модели реализуются.
ГВ>>Обеспечением необходимой функциональности занимается App-ядро, которое вообще-то пишется совсем не ради отложенных транзакций, а ради однократной и реюзабельной реализации ряда возможностей, в том числе — объектно-ориентированного программированиябизнес-логики (см. Object-Relational Mapping, например). M>И которое с тем же успехом может быть написано и в stateless модели. Ровно с тем же самым ORM.
Ну пиши. Особливо — "ровно с тем же самым ORM".
M>С другой стороны, опять-таки можно реализовать тот же самый stateful и без отложенных транзакций. M>Нафига они вообще нужны ты так и не объяснил.
Для снижения нагрузки на SQL-сервер, только и всего.
ГВ>>Причины всё те же самые: скорость исполнения и удобство программирования в ряде случаев. M>Выигрыш в скорости если и есть, то совсем мизерный. Удобства тоже никакого, скорее привычка.
Ну, это твоё собственное ХО. Если ты себя убедил в том, что "stateless — рулез форева", то тоже неплохо.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Нет, stateful может быть и без отложенных транзакций, просто они очень естественно в этой модели реализуются.
В отложенных транзакциях нет ничего естественного..
ГВ>Для снижения нагрузки на SQL-сервер, только и всего.
Много там не на снижаешься..
В stateful узкое место уже не сиквел, а как раз app-ядро. А ты его еще заставляешь сиквеловскую работу по durability и recovery выполнять.
ГВ>Ну, это твоё собственное ХО. Если ты себя убедил в том, что "stateless — рулез форева", то тоже неплохо.
Да тут речь даже не о stateless vs stateful, а о том, что отложенные транзакции — это полная задница.
И если stateful без них сделать проблематично, то тем хуже для stateful.
Здравствуйте, Merle, Вы писали:
ГВ>>Нет, stateful может быть и без отложенных транзакций, просто они очень естественно в этой модели реализуются. M>В отложенных транзакциях нет ничего естественного..
Ну, смотря откуда посмотреть.
ГВ>>Для снижения нагрузки на SQL-сервер, только и всего. M>Много там не на снижаешься.. M>В stateful узкое место уже не сиквел, а как раз app-ядро. А ты его еще заставляешь сиквеловскую работу по durability и recovery выполнять.
Здесь нужно добавлять "на мой взгляд", или "ИМХО".
ГВ>>Ну, это твоё собственное ХО. Если ты себя убедил в том, что "stateless — рулез форева", то тоже неплохо. M>Да тут речь даже не о stateless vs stateful, а о том, что отложенные транзакции — это полная задница. M>И если stateful без них сделать проблематично, то тем хуже для stateful.
Ещё раз. Stateful вовсе не означает "отложенные транзакции", а вот отложенные транзакции — означает stateful. Т.е., не имея stateful транзакции отложить сложно, но можно. А если есть stateful-ядро, то их откладывать можно, хотя и не обязательно.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Если нам не помогут, то мы тоже никого не пощадим.
Как ты интересно своему объекту жизнь продлеваешь? Или он у тебя на сервере висит пока сервер не перегрузят?
Но я не об этом спрашивал. Хорошо, поставим вопрос по-другому. Что баба Маня сможет сделать? Ну, из каких вариантов будет у неё выбор? И как будет клиент (и/или сервер) обрабатывать выборы бабы Мани?
Мы уже победили, просто это еще не так заметно...
ИМХО, если нельзя учесть очередной вираж законодательства ОДНИМ ТОЛЬКО обновлением конфигурационных данных в БД (частный случай хранения конфигурации), то надо переписать часть БЛ и передеплоить оную.
