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

IT>>И используется только этим клиентом. Ну наконец-то
IT>>Тогда у меня вопрос. А нафига козе баян? Идея хранить данные на сервере, которые нужны только одному клиенту,

AVK>И рантайму сервера для обеспечения long running транзакций

Так дело всё в том, что эти транзакции создаются только с одной целью — создать эти транзакции. Ни какой реальной необходимости в них нет.

IT>>Так вот я у тебя его и прошу

AVK>А как это должно выглядеть с моей стороны?

Нужет e-mail или телефон, который знает Стив и который сможет по нему однозначно тебя по нему отождествить

AVK>>>Что невозможно создать идеально масштабируемую архитектуру

IT>>Т.е. "невозможно создать идеально масштабируемую архитектуру" потому что java плохо работает с вебсервисами? Найс.

AVK>Нет, потому что нельзя заранее предусмотреть всех необходимостей.

Блин, всё, надоело

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

AVK>>Ну напиши МС чтобы убрали кеш из MSSQL.

IT>Ну такого наглого выдёргивания из контекста я ещё не видел

IT>

IT>А ты уверен, что такой малоэффективный кэш вообще нужен? Часто изменяемые данные лучше всего кешируются самим sql сервером и не как объекты, а как сырые страницы файла данных.

IT>Андрей, как тебе не стыдно!

Нет, я не понял, а чем кеш на sql лучше кеша в сервере приложений?

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

AVK>>И рантайму сервера для обеспечения long running транзакций

IT>Так дело всё в том, что эти транзакции создаются только с одной целью — создать эти транзакции. Ни какой реальной необходимости в них нет.

А кто тогда откатывать или коммитить в БД будет?

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

M>>>Но системный код — тоже не боги пишут, в БД все формализовано и алгоритмы стандартные, плюс все отлаживали десятилетиями.
H_D>>Ну, SQL тоже не боги писали... да и пишут

IT>Это да. Но если учесть, что они в два раза менее профессиональнее тебя и у них уходит аж 4 часа на написание b-дерева, то представляешь сколько b-деревьев они за несколько понаписали

Не, у них скорее всего месяца полтора на новое b-дерево уйдёт. И одних маркетинговых исследований — миллиона на два баксов. Типа, чтобы доказать, что новое b-дерево зашибёт Sun, IBM и Oracle вместе взятых.

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

IT>>Так дело всё в том, что эти транзакции создаются только с одной целью — создать эти транзакции. Ни какой реальной необходимости в них нет.

AVK>А кто тогда откатывать или коммитить в БД будет?

А кто их сейчас коммитит?

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

TK>Были американцы на луне или нет, но сейчас обсуждение stateless vs statefull выглядит так: со стороные stateless есть конкретные технологии и готовые программные продукты. Со стороны statefull есть лишь абстрактный апп сервер который может все по определению (с максимальной эффенктивностью). Вобщем — хотелось-бы видеть конкретные продукты и приимеры реализации. Может тогда и вопросы сами собой отпадут?

У MS со stateful, действительно, НЕ СРОСЛОСЬ. Но это не значит, что у других то же самое.
Что-нибудь слышали о Sun J2EE? В EJB, в частности Stateful Session Bean, Вам не о чём не говорит.

TK>Вот например сервер без GC. Замечательно — давайте рассмотрим stateless vs COM+ и реализация бизнес объектов на С++?

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

IT>>>Так дело всё в том, что эти транзакции создаются только с одной целью — создать эти транзакции. Ни какой реальной необходимости в них нет.

AVK>>А кто тогда откатывать или коммитить в БД будет?

IT>А кто их сейчас коммитит?

Сервер приложений, точнее его подсистема управления длинными транзакциями. Или ты предлагаешь транзакции поднимать сразу в БД?

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

ГВ> Типа, чтобы доказать, что новое b-дерево зашибёт Sun, IBM и Oracle вместе взятых.
Гы, но весь прикол в том, что в итоге действительно зашибает..

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

ZEN>>Что скажете? Интересно было бы послушать альтернативщиков платформы MS, прежде всего из стана Java.
AS>Слушаем тебя с нетерпением.

Не подменяйте посылку.

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

AVK>>Давай не будем ограничивать свои знания продуктами МС. Названия WebLogic, EAS тебе о чем нибудь говорят?

IT>Говорят о тормознутости. Говорят об использовании мощных и дорогих санов для того чтобы это хоть как-то дышало. Говорят о системах под ключ стоимостью в десятки раз больше чем аналогичные для Windows.

Скажите это тем бедолагам, которые корчатся в муках, отлаживая свои творения в JBuilder, WebSphere, JDeveloper и др. Из Ваших слов очевидно, что им давно пора застрелиться. Ан нет, что-то ковыряют в EJB, отлаживают на локальных машинах.

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

IT>>Она у меня уже есть по умолчанию. Называется веб-сервисы

AVK>Ну попробуй свой вебсервис где нить в джаве заюзать, потом вместе смеятся будем

После прочтения вот этого http://ru.sun.com/pdf/j2ee/WST.pdf будет ли смешно?

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

ГВ>> Типа, чтобы доказать, что новое b-дерево зашибёт Sun, IBM и Oracle вместе взятых.
M>Гы, но весь прикол в том, что в итоге действительно зашибает..

Ну, значит, славный баобаб получился.

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

ZEN>Скажите это тем бедолагам, которые корчатся в муках, отлаживая свои творения в JBuilder, WebSphere, JDeveloper и др. Из Ваших слов очевидно, что им давно пора застрелиться. Ан нет, что-то ковыряют в EJB, отлаживают на локальных машинах.

Тёмные оне, не просвещённые. Да и делать лёгкий, быстрый софт совсем не в их интересах. Если они будут быстро и качественно писать, то чем они будут обосновывать такие цены на свои продукты.
Боюсь что после их санов им уже ничего не поможет

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

IT>>А кто их сейчас коммитит?

AVK>Сервер приложений, точнее его подсистема управления длинными транзакциями. Или ты предлагаешь транзакции поднимать сразу в БД?

Я для начала хочу понять какими были первоначальные требования. Пока у меня сложилась следующая картина. Баба Маня вводит документ и он уходит на сервер, на сервере он живёт до тех пор, пока баба Маня возится с другими его частями, после чего говорит "Огонь" и весь этот паровоз едет в базу данных. Правильно?

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

IT>Я для начала хочу понять какими были первоначальные требования. Пока у меня сложилась следующая картина. Баба Маня вводит документ и он уходит на сервер, на сервере он живёт до тех пор, пока баба Маня возится с другими его частями, после чего говорит "Огонь" и весь этот паровоз едет в базу данных. Правильно?
Слушай! У меня именно такие требования быви в одной из работ...
Так что ты привел вполне жизненый пример..
комментарий: бабу Маню млжет звали Дусей, но у нее было 4 класса образования и слово из 15 символов она вводила минуты 3-4...

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

IT>Я для начала хочу понять какими были первоначальные требования. Пока у меня сложилась следующая картина. Баба Маня вводит документ и он уходит на сервер, на сервере он живёт до тех пор, пока баба Маня возится с другими его частями, после чего говорит "Огонь" и весь этот паровоз едет в базу данных. Правильно?

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

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

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

Понял. Моё решение могло бы быть таким.
Баба Маня вводит документы локально. При необходимости посчитать что-то на сервере ему выдаются необходимые данные и он их считает. Если баба Маня нажимает Esc, то всё умирает не обращаясь к серверу. Если она нажимает Save, то сервер все данные сохраняет одной транзакцией.

Stateless в чистом виде

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

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

IT>Понял. Моё решение могло бы быть таким.
IT>Баба Маня вводит документы локально. При необходимости посчитать что-то на сервере ему выдаются необходимые данные и он их считает.

Вот здесь главная закавыка. Логика, которая определяет необходимые данные, вероятно, "уходит" на клиента.

IT>Если баба Маня нажимает Esc, то всё умирает не обращаясь к серверу. Если она нажимает Save, то сервер все данные сохраняет одной транзакцией.

IT>Stateless в чистом виде

То-то и оно, что stateless, да ещё и с разгруженным SQL-сервером. Сначала тебе нужно гонять избранные фрагменты (которые нужно программить вручную) для обсчёта промежуточных величин, а потом — полное тело документа. Плюс — обработать разные хитрые ситуации отказов промежуточного обсчёта и т.п. Плюс — продублировать вычисления после отправки завершённого документа.

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

IT>Понял. Моё решение могло бы быть таким.
IT>Баба Маня вводит документы локально.

Опаньки. Значит состояние надо на клиенте держать? Проблемы перечислить или и так понятно?

IT>При необходимости посчитать что-то на сервере ему выдаются необходимые данные и он их считает.

Абалдеть. ООП в действии . Данные отдельно, алгоритмы отдельно. Только вот нифига не выйдет так — в алгоритмах рассчетов практически всегда фигурируют только что введенные данные. Единственный способ в таком варианте — гнать данные на сервер. Это тот самый случай когда стейтлес вносит жуткий оверхед, что и требовалось доказать.

IT> Если баба Маня нажимает Esc, то всё умирает не обращаясь к серверу.

А если в процессе ввода документов нужно автоматически добавлять какие то объекты? На клиенте добавлять? Но это ведб БЛ, а она допустима только на сервере!

IT> Если она нажимает Save, то сервер все данные сохраняет одной транзакцией.

IT>Stateless в чистом виде

Ага.

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

H_D>Слушай! У меня именно такие требования быви в одной из работ...
H_D>Так что ты привел вполне жизненый пример..
H_D>комментарий: бабу Маню млжет звали Дусей, но у нее было 4 класса образования и слово из 15 символов она вводила минуты 3-4...

Баба Маня или Дуся — это непременное негласное требование любого ТЗ.