Здравствуйте, Tom, Вы писали:
TK>>А теперь давай положим в эту табличку пару миллионов записей, и начнем выбирать данные из случайного места. И еще не забудь добавить в свой тестик обновление кеша — данные меняются и кеш надо иногда перезагружать. А для пущей реальности, добавим еще пару табличек роли — там какие-нибудь и еще какой-нибудь ерунды в том-же стиле... Плюс сделаем вид, пользователи иногда логинятся — так что, поищем еще и по имени... TK>>И тогда, мы еще раз поиграем в спасателей. Только боюсь как-бы M2 не пролетел мимо дерева Tom>А не надо везде, где не надо звать спасателей. У них работа другая. Я тебе хотел всего лишь показать, что не всегда правильно всё пихать на сервер БД. Умный кэш — это хорошее решение. Я ж не спорю, что база данных это зэ бэст. Я говорю, что можно сделать ещё лучше и мой тест — всего лишь тому подтверждение.
в твоем примере — умным решением было-бы закешировать результат "SELECT * FROM users where id=4" (что и было-бы сделано в ральной архитектуре), а не тянуть всю таблицу к себе. Вот и оцени трудо затраты — "выборка из базы + кеширование на пару секунд" против полноценной реализации из второго варианта.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Hacker_Delphi, Вы писали:
TK>>Вобщем — какие-то не верные выводы... Можно тоже самое и про statefull написать. H_D>Да ну? КАК ты добъешься актуальности данных в стейтлесс? будешь постоянно сдергивать с сервера "изменения за период времени"?? так это же твою сеть положит... H_D>а сервер оповещать не сможет... он же стейтлесс — даже если он знает сколько у него клиентов — он что на каждый чих будет оповещать ВСЕХ??? H_D>а если их 100 000?
А сервер у тебя тоже будет 100 000 клиентов уведомлять и ссылки на них держать? А если один отвалился (не на долго, совсем на чуть-чуть)? А если клиент за firewall?
Я-то поставлю SQL Server Notification Services и думать забуду о количестве пользователей. А что будешь делать ты? Какой велосипед придется создать на этот раз?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, IT, Вы писали:
IT>Я боюсь, что ты не верно истолковал мои слова. Когда я говорю о целостности БД, я имею ввиду только проверку связей и допустимость значений. Т.е. FK и констрейнты. О тригерах я ничего не говорил.
К несчастью, FK не всегда применимы...
у меня в системе они не применимы вообще, потому, что объект на который ссылаемся может совсем в разных таблицах лежать... и ничего с этим не поделаешь...
... << RSDN@Home 1.1.2 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
TK>в твоем примере — умным решением было-бы закешировать результат "SELECT * FROM users where id=4" (что и было-бы сделано в ральной архитектуре), а не тянуть всю таблицу к себе. Вот и оцени трудо затраты — "выборка из базы + кеширование на пару секунд" против полноценной реализации из второго варианта.
Да ёлы палы. Что ето со всеми. Я ещё раз повторяю. Пример с потолка. Предназначегн только для того, что бы показать, что не надо всё ложить на базу! Больше ничего я им сказать не хотел.
Здравствуйте, Tom, Вы писали:
Tom>Да ёлы палы. Что ето со всеми. Я ещё раз повторяю. Пример с потолка. Предназначегн только для того, что бы показать, что не надо всё ложить на базу! Больше ничего я им сказать не хотел.
Тогда соило использовать не базу, а текстовый файл. Или просто константу к потолку прибить.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Hacker_Delphi, Вы писали:
TK>>>Вобщем — какие-то не верные выводы... Можно тоже самое и про statefull написать. H_D>>Да ну? КАК ты добъешься актуальности данных в стейтлесс? будешь постоянно сдергивать с сервера "изменения за период времени"?? так это же твою сеть положит... H_D>>а сервер оповещать не сможет... он же стейтлесс — даже если он знает сколько у него клиентов — он что на каждый чих будет оповещать ВСЕХ??? H_D>>а если их 100 000?
TK>А сервер у тебя тоже будет 100 000 клиентов уведомлять и ссылки на них держать? А если один отвалился (не на долго, совсем на чуть-чуть)? А если клиент за firewall? TK>Я-то поставлю SQL Server Notification Services и думать забуду о количестве пользователей. А что будешь делать ты? Какой велосипед придется создать на этот раз?
Так, я не понял... если мы говорим о стейтлесс — какой SQL Server Notification Services?? а если мы храним контекст пользователя — это не стейтлесс..
кстати, нашел еще одну задачу, где WebServices рулят перед Remoting'ом — при написании клиентов под CompactFramework
... << RSDN@Home 1.1.2 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, TK, Вы писали:
AVK>>Если транзакция распространяется на несколько методов то уже не стейтлес, ибо транзакция суть состояние.
TK>Это уже не состояние, а демагогия.
А по мне так самое натуральное состояние. Иначе непонятно что же тогда вобще состояние.
TK>С тем-же успехом можно сказать, что транзакция это процесс перехода из одного устойчивого состояния в другое устойчивое состояние.
Можно. А что это даст?
TK>А учитывая, что две разных транзакции изолированы друг от друга — можно сказать, внутрее состояние транзакции является неопределенной величиной для стороннего наблюдателя.
Ну смотря какой наблюдатель. Если наблюдатель из другой транзакции то да.
TK> Так что-же это за состояние, которое нельзя ни измерить, ни увидеть?
Его можно и измерить и увидеть службам сервера приложений и собственно участнику транзакции.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет, если уж у нас запись отложеная то естественно ни о какой durability и речи быть не может.
Ну дык и я об том же..
M>>Если же применяется UNDO схема — все не зафиксированные изменения держатся в памяти, то в силу того, что незафиксированых изменений, при большой нагрузке, может быть довольно много, будет происходить перерасход памяти. M>>То есть сервер вносит изменения на диск, потому что в большинстве случаев так выгоднее.
AVK>А вот тут я бы не стал обобщать.
А я и не обобщаю.. Я очень аккуратно написал "в большинстве случаев". На самом деле схема с undo/redo достаточно гибкая, чтобы пока память есть, диск не трогать, а как только память становится нужна для более других нужд, то незафиксированные данные можно себе позволить скинуть в лог.
Здравствуйте, Tom, Вы писали:
M>>А когда ты ее начать успел? У тебя же все в памяти.... Tom>Ты меня совсем не понял. Вот скажем то о чм я говорю:
Нет это ты не понял..
Про откат все ясно, не ясно про фиксацию...
Tom>Я не хотел ничего никуда на диск пихать.
А надо. В том-то вся и проблема, что надо, и от этого не отвертеться.
Здравствуйте, AndrewVK, Вы писали:
AVK>А кто? Точно не я
ГВ, а Tom его поддерживает почему-то..
AVK>Отложеная запись это совершенно отдельный разговор. Мы же пока, надеюсь, говорим о stateless vs stateful.
Не, у нас тут как раз тот самый отдельный разговор..
Здравствуйте, Merle, Вы писали:
AVK>>А вот тут я бы не стал обобщать. M>А я и не обобщаю.. Я очень аккуратно написал "в большинстве случаев".
Знаешь как ты писал, осторожно или держа по ножу в каждой руке и отчаяно ими махая, я не видел. Но когда человек говорит в большинстве случаев он имхо обобщает.
Здравствуйте, Merle, Вы писали:
AVK>>Отложеная запись это совершенно отдельный разговор. Мы же пока, надеюсь, говорим о stateless vs stateful. M>Не, у нас тут как раз тот самый отдельный разговор..
То есть пьянка перешла в следующую стадию и народ разбился на кучки по интересам?
Здравствуйте, Hacker_Delphi, Вы писали:
TK>>А сервер у тебя тоже будет 100 000 клиентов уведомлять и ссылки на них держать? А если один отвалился (не на долго, совсем на чуть-чуть)? А если клиент за firewall? TK>>Я-то поставлю SQL Server Notification Services и думать забуду о количестве пользователей. А что будешь делать ты? Какой велосипед придется создать на этот раз? H_D>Так, я не понял... если мы говорим о стейтлесс — какой SQL Server Notification Services?? а если мы храним контекст пользователя — это не стейтлесс..
Нет никакого контекста пользователя. Клиент просто вызывает веб метод, где указывает свой endpoint и в каких уведомлениях он заинтересован. Никакого глобального состояния в памяти держать не надо — это примитивная операция которая сравни подписке на любую рассылку.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, IT, Вы писали: IT>Я боюсь, что ты не верно истолковал мои слова. Когда я говорю о целостности БД, я имею ввиду только проверку связей и допустимость значений. Т.е. FK и констрейнты. О тригерах я ничего не говорил.
А, ну в таком случае я полностью согласен. Я как раз защищал декларативные констрейнты, ибо они дают пищу для ума оптимизатора. А все процедурные констрейнты (типа триггеров) мне очень хочется перенести в App-сервер.
... << RSDN@Home 1.1.0 stable >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
IT>>Это обсуждение мы давай лучше отложим. Я лишь намекну, что на stateless сделать можно всё, т.к. название эта модель получила не из-за того, что состояния в ней нет, а из-за того, что серверные объекты бизнес логики ака сервисы в терминах Дон Бокса, манипулируя этими состояниями, в себе самих их не хранят.
AVK>Не, IT, ты уже начинаешь собственное толкование термина сочинять. Стейтлес озночает ничто иное как отсутствие состояния. Если оно наличествует значит это уже не стейтлес.
Хм. горячие парни. Я как-то полагал, что страшное слово stateless относится именно к модели сервера приложений, в которой он отказывается от хранения состояния. При этом он полностью полагается на DBMS (ну, или в более широком смысле слова — на произвольный нижележащий уровень) в том, что касается состояния системы. Надо отметить, что совсем stateless системы — это не более чем игрушка для ума, набор процедурной логики. Складывалка 2+2 — один из примеров. Все интересные сиситемы помимо поведения должны поддерживать еще и состояние. Но это никак не противоречит выбору stateless модели для одного из уровней системы, пока нижние уровни несут на себе этот state.
... << RSDN@Home 1.1.0 stable >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Tom, Вы писали:
Tom>Я тебе хотел всего лишь показать, что не всегда правильно всё пихать на сервер БД.
Да кто бы спорил.
Tom> Умный кэш — это хорошее решение.
Но в твоем примере кэш глупый. Нет смысла кешировать датасет, после этого ты с ним ничего сделать не сможешь.
А тебе по этому набору юзеров надо еще агрегатов понаделать (которые, к слову обновляются гораздо чаще, чем отдельно взятый юзер), приделать проверку прав и еще кучу всякой лабуды, на которой твой замечательный датасет просто сдуется.
А если на этом деле еще и полноценную секюрити делать надо будет, то все станет совсем грустно.
Здравствуйте, AndrewVK, Вы писали:
TK>>Были американцы на луне или нет, но сейчас обсуждение stateless vs statefull выглядит так: со стороные stateless есть конкретные технологии и готовые программные продукты. Со стороны statefull есть лишь абстрактный апп сервер который может все по определению (с максимальной эффенктивностью).
AVK>Давай не будем ограничивать свои знания продуктами МС. Названия WebLogic, EAS тебе о чем нибудь говорят?
Говорят о тормознутости. Говорят об использовании мощных и дорогих санов для того чтобы это хоть как-то дышало. Говорят о системах под ключ стоимостью в десятки раз больше чем аналогичные для Windows.
Если нам не помогут, то мы тоже никого не пощадим.
Мы уже победили, просто это еще не так заметно...
Если нам не помогут, то мы тоже никого не пощадим.
