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

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

S>>Включение/отключение аппаратного кэширования всего лишь влияет на этот MTBF,

AVK>MTBF — среднее время наработки на отказ. Обычно 20-50 тыс. часов. Включение/отключение аппаратного кеша на MTBF не влияет, оно увеличивает вероятность аппаратного сбоя из-за глюков фирмваре, электроники, космических лучей. MTBF у электроники по сравнению с винтом огромен и составляет десятки лет, следовательно на MTBF системы в целом практически не влияет.

AVK>По моему у тебя неверное понимание термина MTBF.
А по-моему у тебя. Не имеет смысла говорить о MTBF какого-то отдельного компонента. Вот ты говоришь "Включение/отключение аппаратного кеша на MTBF не влияет, оно увеличивает вероятность аппаратного сбоя из-за ...". Зашибись, как это у нас может измениться вероятность сбоя, а мат. ожидание промежутка между сбоями не изменится? Получается, ты просто меришь mean time между одними сбоями, а учитываешь вероятность других. Вероятность получить сбой на промежутке длиной T однозначно связана с мат. ожиданием длины промежутка.
В итоге, я говорю о том, что мне по барабану, сколько часов подряд может крутиться двигатель винта. Я говорю о том, что с выключенным кэшированием сбой винта (т.е. невозможность прочитать записанные данные) возникает раз в NNNN часов, а со включенным — раз в NNNN/X часов. И именно этот суммарный MTBF и играет роль в оценке надежности моего приложения.

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

S>А по-моему у тебя. Не имеет смысла говорить о MTBF какого-то отдельного компонента. Вот ты говоришь "Включение/отключение аппаратного кеша на MTBF не влияет, оно увеличивает вероятность аппаратного сбоя из-за ...". Зашибись, как это у нас может измениться вероятность сбоя, а мат. ожидание промежутка между сбоями не изменится?

http://www.webopedia.com/TERM/M/MTBF.html

Short for mean time between failures, the average time a device will function before failing. MTBF ratings are measured in hours and indicate the sturdiness of hard disk drives and printers.
Typical disk drives for personal computers have MTBF ratings of about 500,000 hours. This means that of all the drives tested, one failure occurred every 500,000 hours of testing. Disk drives are typically tested only a few hours, and it would be unlikely for a failure to occur during this short testing period. Because of this, MTBF ratings are also predicted based on product experience or by analyzing known factors such as raw data supplied by the manufacturer.

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

ГВ>>Вот любишь же ты это "в принципе нельзя". Нет никакой ложки, всё — обман. (c) The Matrix
M>Каюсь, грешен. ж) — Это внутренний констрэйнт, низя, значит низя, потому, что если чуть-чуть можно, то границы этого чуть-чуть определить очень сложно, а разгребать потом накладно. Проще сразу, низя и все..

Вот тут-то мы с тобой и не совпадаем.

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

IT>>Тогда нам тяжело будет беседовать. Мне всегда было интересно знать физику процесса, а не рассказы о том, что она есть.

AVK>Ну я вроде как и не тебе отвечал, а немного другому IT. Если хочешь услышать что то конкретное от меня — задай вопрос отдельно.

Думаешь получится?

IT>>Как я понял твои транзакции начинаются и заканчиваются в разных местах разными участниками. Разве не так?

AVK>Нет конечно, с чего ты взял?

Т.е. это всё делается одним клиентом на одной машине, так?

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

AVK>Не буду

Ну вот, а говоришь задавай вопросы

IT>>Дашь референс?

AVK>А он что, публично недоступен? stevesw@microsoft.com

Не, буз референса мне его секретарша ответит или спам фильтр отфильтрует.

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

IT>>Я ими связывал .NET и Java. Особых проблем у меня на стороне .NET не было

AVK>А на стороне джавы?

А это были не мои проблемы.

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

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

S>>А по-моему у тебя. Не имеет смысла говорить о MTBF какого-то отдельного компонента. Вот ты говоришь "Включение/отключение аппаратного кеша на MTBF не влияет, оно увеличивает вероятность аппаратного сбоя из-за ...". Зашибись, как это у нас может измениться вероятность сбоя, а мат. ожидание промежутка между сбоями не изменится?

AVK>http://www.webopedia.com/TERM/M/MTBF.html

AVK>

AVK>Short for mean time between failures, the average time a device will function before failing. MTBF ratings are measured in hours and indicate the sturdiness of hard disk drives and printers.
AVK>Typical disk drives for personal computers have MTBF ratings of about 500,000 hours. This means that of all the drives tested, one failure occurred every 500,000 hours of testing. Disk drives are typically tested only a few hours, and it would be unlikely for a failure to occur during this short testing period. Because of this, MTBF ratings are also predicted based on product experience or by analyzing known factors such as raw data supplied by the manufacturer.

Не вижу в процитированном никаких противоречий с моим мнением.

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

AVK>>Ну я вроде как и не тебе отвечал, а немного другому IT. Если хочешь услышать что то конкретное от меня — задай вопрос отдельно.

IT>Думаешь получится?

Это уж как настроение у меня будет

IT>>>Как я понял твои транзакции начинаются и заканчиваются в разных местах разными участниками. Разве не так?

AVK>>Нет конечно, с чего ты взял?

IT>Т.е. это всё делается одним клиентом на одной машине, так?

1 транзакция? Одним клиентом конечно. Попытка влезть из другой транзакции немедленно вызывает исключение. Насчет одной машины не понял.

IT>>>Дашь референс?

AVK>>А он что, публично недоступен? stevesw@microsoft.com

IT>Не, буз референса мне его секретарша ответит или спам фильтр отфильтрует.

Так, тогда объясни мне что такое референс.

AVK>>А на стороне джавы?

IT>А это были не мои проблемы.

Вот видишь — ты заранее оговорил что использование твоих сервисов из джавы ты не закладываешь. ЧТо и требовалось доказать.

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

AVK>>>Вобщем опять сплошное определение погоды по почтовому индексу. Может в штатах это и актуально, а вот в России пока нет, и подобные технологии вряд ли станут особо востребованными.

IT>>А кто у вас определяет востребованность?

AVK>Заказчик, разумеется. Конкретно для меня куча народа, ответственная за стратегию дальнейшего развития фирмы в целом и конкретного проекта в частности.

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

IT>>Скоро будут и в Индиге.

AVK>В индиге много чего будет. Вон веб-сервисы с самого первого фреймворка есть, только рулежа что то не особенно заметно, по крайней мере в России. Один DigiDes чего то там дергался, но выхлоп совсем бледный какой то.

Ну почему же. Хорошая штука для связывания разношёрстных систем. Да и янус вон как-то дышит

IT>>>>Это обсуждение мы давай лучше отложим. Я лишь намекну, что на stateless сделать можно всё, т.к. название эта модель получила не из-за того, что состояния в ней нет, а из-за того, что серверные объекты бизнес логики ака сервисы в терминах Дон Бокса, манипулируя этими состояниями, в себе самих их не хранят.

AVK>Ну так перечитай себя. У тебя под стейтлес явно подразумевается что то куда более хитрое. Ну типа есть кошерный стейтлес и некошерный стейтлес (не по Боксу)

Ну так откати на пару сообщений вверх и перечитай сам, а не выдёргивай из контекста. Ты начал с того, что объектов без состояния не бывает, так вот я тебе и другим объясняю, что название stateless эта модель дала благодаря не тем объектам о которых ты говоришь.

IT>> Вопрос в том, о какмх именно объектах идёт речь. Не надо зацикливаться на своём stateful, состояние и управление им может быть лекго разделено и при этом можно получить массу преимуществ.

AVK>Да, вот как раз меня и надо обвинять в зацикливании на какой то модели
AVK>Я говорю что нужно выбирать модель по задаче, от тебя в ответ — конечно же надо, но стейтлес все равно лучше . Так кто из нас зацикливается?

Конечно же stateless лучше. И тебе тут уже неоднакратно это продемонстрировали. Но ты всё продолжаешь бубнить "не надо говорить, что stateless лучше".

IT>>Это ты насчёт преимуществ?

AVK>Это насчет никаких недостатков. Недостатки есть у обоих моделей и глупо их игнорировать.

Естественно. Редко приходится выбирать между хорошим и отличным. Чаще приходится между плохим и очень плохим. Но в данном случае нам повезло, у нас есть выбор между плохим (stateful) и приемлемым (stateless)

А вообще, давай завязывать этот спор. Кому надо тот всё понял, кому не надо, тому бесполезно что-то объяснять.

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

IT>>Возможно. Но скорее всего ты додумал то, что хотел

AVK>То что помимо меня точно так же додумал и Синклер наводит на размышления, не находишь?

Видимо он от тебя заразился

AVK>Да нет, IT прав, чтобы обеспечить нормальное питание винта несколько миллисекунд нужны конденсаторы размером с этот винт. На самом деле все проще — конденсаторы обеспечивают только питание электроники головки и буферной памяти. Вся остальная электроника вырубается, а вращение пластин обеспечивается за счет инерции.

Дык а кто говорил, что из кондёров питаются движки? Ессно только головка.

PS: Tnx что попрвил.

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

IT>Конечно же stateless лучше. И тебе тут уже неоднакратно это продемонстрировали. Но ты всё продолжаешь бубнить "не надо говорить, что stateless лучше".
Справедливости ради, надо заметить, что, по крайней мере изначально, он бухтел "не надо говорить, что stateless всегда лучше"

AVK>>>>Вобщем опять сплошное определение погоды по почтовому индексу. Может в штатах это и актуально, а вот в России пока нет, и подобные технологии вряд ли станут особо востребованными.

IT>>>А кто у вас определяет востребованность?

AVK>>Заказчик, разумеется. Конкретно для меня куча народа, ответственная за стратегию дальнейшего развития фирмы в целом и конкретного проекта в частности.

IT>А... ну раз заканчики, то я бы на твоём месте не стал так громко за них отвечать. Сегодня они этого не хотят, завтра захотят. Бизнес штука непредсказуемая.

Вот когда захотят тогда и будем делать, а пока что ...

AVK>>В индиге много чего будет. Вон веб-сервисы с самого первого фреймворка есть, только рулежа что то не особенно заметно, по крайней мере в России. Один DigiDes чего то там дергался, но выхлоп совсем бледный какой то.

IT>Ну почему же. Хорошая штука для связывания разношёрстных систем.

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

IT>Да и янус вон как-то дышит

Ты знаешь, он бы дышал ничуть не хуже, если бы там был СОМ+ или ремоутинг. Тем более что янус это чистейший стейтлес, и сделан таким преднамеренно. Там даже в БД никакого состояния не хранится, состояние отсутствует как класс.

AVK>>Да, вот как раз меня и надо обвинять в зацикливании на какой то модели
AVK>>Я говорю что нужно выбирать модель по задаче, от тебя в ответ — конечно же надо, но стейтлес все равно лучше . Так кто из нас зацикливается?

IT>Конечно же stateless лучше.



IT>И тебе тут уже неоднакратно это продемонстрировали. Но ты всё продолжаешь бубнить "не надо говорить, что stateless лучше".

Правильно, не надо. There is no silver bullet. Все зависит от конкретной задачи.

AVK>>Это насчет никаких недостатков. Недостатки есть у обоих моделей и глупо их игнорировать.

IT>Естественно. Редко приходится выбирать между хорошим и отличным. Чаще приходится между плохим и очень плохим. Но в данном случае нам повезло, у нас есть выбор между плохим (stateful) и приемлемым (stateless)

Не обобщай.

IT>А вообще, давай завязывать этот спор. Кому надо тот всё понял, кому не надо, тому бесполезно что-то объяснять.

ОК.

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

IT>>Т.е. это всё делается одним клиентом на одной машине, так?

AVK>1 транзакция? Одним клиентом конечно. Попытка влезть из другой транзакции немедленно вызывает исключение. Насчет одной машины не понял.

Транзакция у тебя открыта на клиенте или на сервере?

IT>>Не, буз референса мне его секретарша ответит или спам фильтр отфильтрует.

AVK>Так, тогда объясни мне что такое референс.

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

IT>>А это были не мои проблемы.

AVK>Вот видишь — ты заранее оговорил что использование твоих сервисов из джавы ты не закладываешь. ЧТо и требовалось доказать.

Что именно доказать?

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

IT>>Не надо выворачивать. Я ничего не говорил о наличии/отсутствии объектных запросов в стайтлес модели.

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

Ты опять что-то путаешь. Это не преимущество stateless, это недостаток stateful.

IT>>Что здесь не так? К тому же чем ближе к клиенту, тем уже более обработаны данные. Или тебе еще раз привести пример с браузером?

AVK>А чем дальше от клиента тем больше и эффективнее может заполняться кеш. Вобщем не надо обобщать

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

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

AVK>>1 транзакция? Одним клиентом конечно. Попытка влезть из другой транзакции немедленно вызывает исключение. Насчет одной машины не понял.

IT>Транзакция у тебя открыта на клиенте или на сервере?

Клиентом на сервере

IT>>>Не, буз референса мне его секретарша ответит или спам фильтр отфильтрует.

AVK>>Так, тогда объясни мне что такое референс.

IT>Референс — это ссылка Нужна для того, чтобы я Стиву написал, что мол так и так, порекомендовал мне тебя твоё корешь Андрюха. Сказал, что можешь ты мне помочь угомонить твоих бойцов, которые тут совсем распоясались... ну и т.п.

Ну можешь написать референс на меня, если поможет

IT>>>А это были не мои проблемы.

AVK>>Вот видишь — ты заранее оговорил что использование твоих сервисов из джавы ты не закладываешь. ЧТо и требовалось доказать.

IT>Что именно доказать?

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

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

AVK>Да я не спорю. Я против обобщения что клиентский кеш всегда лучше.

Слушай, ну сколько можно пользоваться этим тухлым приёмом. Никто ничего не обобщал, это всего лишь твои домыслы. Никто не говорил, что клиентский кеш всегда лучше. Речь была об эффективности, при чём был дан конкретный пример.

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

IT>>Транзакция у тебя открыта на клиенте или на сервере?

AVK>Клиентом на сервере

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

IT>>Референс — это ссылка Нужна для того, чтобы я Стиву написал, что мол так и так, порекомендовал мне тебя твоё корешь Андрюха. Сказал, что можешь ты мне помочь угомонить твоих бойцов, которые тут совсем распоясались... ну и т.п.

AVK>Ну можешь написать референс на меня, если поможет

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

AVK>>>Вот видишь — ты заранее оговорил что использование твоих сервисов из джавы ты не закладываешь. ЧТо и требовалось доказать.

IT>>Что именно доказать?

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

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

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

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

IT>Ты опять что-то путаешь. Это не преимущество stateless, это недостаток stateful.

Это ты чего то путаешь. Это вобще не имеет отношения к модели.

AVK>>А чем дальше от клиента тем больше и эффективнее может заполняться кеш. Вобщем не надо обобщать

IT>А ты уверен, что такой малоэффективный кэш вообще нужен?

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

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

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

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

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

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

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

AVK>>Ну можешь написать референс на меня, если поможет

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

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

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

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

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

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

IT>>Ты опять что-то путаешь. Это не преимущество stateless, это недостаток stateful.

AVK>Это ты чего то путаешь. Это вобще не имеет отношения к модели.

Расскажи это ГВ и Хакеру

IT>>А ты уверен, что такой малоэффективный кэш вообще нужен?

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

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

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

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