Здравствуйте, meowth, Вы писали:
M>Здравствуйте, Mike Chaliy, Вы писали:
MC>>+1. У нас УЖЕ лоад-белансед ферма.
M>Если не NDA, вы как сделали, на основе штатного NLB? А то я уже в сторону 1 nginx + N IIS поглядываю, изучаю вопрос.
Я если чесно не в курсе . Насколько я знаю да, штатный NLB из 2008 винды.
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
M>>>Ничего не придумал, вы сами сказали следующее: "G>>>Ага, теперь нам надо разный код писать для работы с товарами категории X в domain и в reporting." G>>Я констатировал факт. M>Ну а я его опроверг
Чем? Тем что придумали что не будет шарится логика между reporting и domain?
Я привел пример как в anemic шарится логика между такими аспектами (хотя на самом деле там нет разницы), что вы будете опреовергать?
G>>>>Только для этого надо поднять в память сначала весь объект. А это может быть непозволительно долго. M>>>Весь не надо, есть проекции и срезы. Кроме того, инфраструктура обеспечивает совершенно прозрачный для бизнес-скрипта кэш объектов. G>>Да ну? И как делать проекции и срезы с domain model? А в кеш не полностью объекты тянутся? M>Очень просто. Читайте NHibernate API и справочник по HQL. Читайте там, я уже писал, что в кеше лежат "т.н. deghydrated objects", разобранные на данные. Тянутся так, как вы напишете.
И как тогда domain-объекты с неполными данными работают?
То что технически такая возможность есть я не сомневаюсь.
G>>Ну а как же domain model? Что там поймет domain expert? G>>Или снова получается что самая rich модель является таковой процентов на 5-10? M>Не заметил противоречий. В HQL аггрегаты поддерживаются наравне с domain query, для domain expert никакой разницы не наблюдается. M>Пример: M>"from SomeItems as si select si, count(si.children)".List();
И какого типа объекты получатся? Это будут domain objects? Как потом логику применять к результатам такого запроса?
Здравствуйте, Лобанов Игорь, Вы писали:
ЛИ>В случае же, когда нас интересует только один аспект Работника, механизм lazy loading гарантирует нам, что "лишние" данные вообще не будут фигурировать в операции.
Очень наивно так полагать.
Я один раз исправлял один тормзящий код. Тормоза были именно из-за LL. Когда посмотрел профайлером оказалось что на простую на вид операцию к базе шло около сотни запросов.
Посмотрел внутренности, оказалось что в безобидном на вид методе (типа AddItem) было обращение к дочерней коллекции, которая подтягивалась лениво.
А так как был зайдействован Linq2SQL, то он тянул всю коллекцию связнынх объектов на каждое обращение. И метод этот вызывался в цикле.
Отключение LL и загрузка только нужных данных дала офигенный прирост производительности. Для этого понадобилость только 3 строчки написать.
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Теория заключается в том что в обычном двузвенном десктоп приложении при переделке в веб придется переписать только PL. G>>Практика заключается в том что таких случаев до смешного мало, переписывать приходится до 90%. M>В таком случае что anemic, что rich -- разницы с точки зрения трудоемкости развития нету.
Это вообще другая ветка разговора.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, gandjustas, Вы писали:
ВВ>>>Во-первых, бизнес-логика, связанная с, скажем, организацией, необязательно должна быть защита в класс Организация — если эта логика внешняя по отношению к организации, например набор бизнес-правил, оно может (и должна быть) представлена в виде отдельных бизнес-сущностей. G>>И как такой класс назвываться будет? Думаете в предметной области будет такое понятие, как вы придумаете для этого класса?
ВВ>Мне разжевать и в рот положить? Я сказал, что если логика внешняя по отношению к Организации, она не должна содержаться в классе Организация. Если эта логика внешняя, то очевидно "в предметной области" и понятие такое найдется.
Ну это получится сервис в терминах anemic — класс содержащий логику обработки данных, и не содержащий самих данных.
А если детально проанализировать предметную область, то окажется что очень мало объектов на самом деле обладают поведением.
ВВ>>>А если организацию при создании параметризировать сервисом, вызов в который она будет делегировать для получения списка емплоееров? G>>Это будет уже идиотизм. Так как сущности окажутся привязаны к сервисам без необходимости. А в остальном код такой же как в anemic будет.
ВВ>Вот когда придет понимание, что привязка сущностей к сервисам куда лучше лучше чем зависимость сервисов от контрактов сущностей — что противоречит даже большинству сервис-ориентед паттернов — тогда и станет понятно, чем хороша жирная модель.
Давай в коде.
ты предлагаешшь:
class SomeService: ISomeService
{
public void SomeAction(SomeDomainObject o)
{
//blah-blah-blah
}
}
class SomeDomainObject
{
public SomeDomainObject(ISomeSerivice srv)
{
_service = srv;
}
public void SomeAction()
{
_service.SomeAction(this);
}
//Some data
}
//где-то в коде
SomeDomainObject o = _someRepo.getObjectWithInjectedSerice(new SomeService(), ...);
o.SomeAction();
Я предлагаю
class SomeService: ISomeService
{
public void SomeAction(SomeDomainObject o)
{
//blah-blah-blah
}
}
class SomeDataObject
{
//Some data
}
//где-то в коде
SomeDataObject o = _someRepo.Get(...);
var srv = new SomeService();
svr.SomeAction(o);
В моем связность меньше. При этом еще код repository проще будет.
Здравствуйте, gandjustas, Вы писали:
G>Чем? Тем что придумали что не будет шарится логика между reporting и domain? G>Я привел пример как в anemic шарится логика между такими аспектами (хотя на самом деле там нет разницы), что вы будете опреовергать?
Мне показалось, вы привели пример, что в rich эта логика шарится НЕ будет. Его я и опроверг.
G>>>>>Только для этого надо поднять в память сначала весь объект. А это может быть непозволительно долго. M>>>>Весь не надо, есть проекции и срезы. Кроме того, инфраструктура обеспечивает совершенно прозрачный для бизнес-скрипта кэш объектов. G>>>Да ну? И как делать проекции и срезы с domain model? А в кеш не полностью объекты тянутся? M>>Очень просто. Читайте NHibernate API и справочник по HQL. Читайте там, я уже писал, что в кеше лежат "т.н. deghydrated objects", разобранные на данные. Тянутся так, как вы напишете. G>И как тогда domain-объекты с неполными данными работают? G>То что технически такая возможность есть я не сомневаюсь.
Во-первых, очень хорошо, что вы не спорите, что есть такая техническая возможность
Во-вторых, вы что-путаете. Что значит -- "с неполными данными"? В anemic как-то по-другому данные в коде оказываются, без запроса к БД?
G>>>Ну а как же domain model? Что там поймет domain expert? G>>>Или снова получается что самая rich модель является таковой процентов на 5-10? M>>Не заметил противоречий. В HQL аггрегаты поддерживаются наравне с domain query, для domain expert никакой разницы не наблюдается. M>>Пример: M>>"from SomeItems as si select si, count(si.children)".List(); G>И какого типа объекты получатся? Это будут domain objects? Как потом логику применять к результатам такого запроса?
Того типа, в который вы сконвертите. Ну если вы просили аггрегаты показать, значит, есть такой domain объект, в котором представим аггрегат. Логику применять -- как обычно.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Лобанов Игорь, Вы писали:
ЛИ>>В случае же, когда нас интересует только один аспект Работника, механизм lazy loading гарантирует нам, что "лишние" данные вообще не будут фигурировать в операции.
G>Очень наивно так полагать. G>Я один раз исправлял один тормзящий код. Тормоза были именно из-за LL. Когда посмотрел профайлером оказалось что на простую на вид операцию к базе шло около сотни запросов. G>Посмотрел внутренности, оказалось что в безобидном на вид методе (типа AddItem) было обращение к дочерней коллекции, которая подтягивалась лениво. G>А так как был зайдействован Linq2SQL, то он тянул всю коллекцию связнынх объектов на каждое обращение. И метод этот вызывался в цикле. G>Отключение LL и загрузка только нужных данных дала офигенный прирост производительности. Для этого понадобилость только 3 строчки написать.
Имхо вы тут путаетесь. Как LL может повлиять на то, что в цикле будут вытягиваться лишние данные? Как он может повлиять на то, что по каждому обращению данные будут вытягиваться заново из БД (объектный 2хуровневый кеш таки рулит(?
ИМХО то, что linq2sql не дает настроить batch size loading в LL еще не значит, что LL -- это плохо и тормозно.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Лобанов Игорь, Вы писали:
ЛИ>>В случае же, когда нас интересует только один аспект Работника, механизм lazy loading гарантирует нам, что "лишние" данные вообще не будут фигурировать в операции.
G>Очень наивно так полагать.
Я всё же предлагаю разделять случаи, когда "должно, но не работает" и "в принципе не должно". Первое лечится багфиксингом, второе -- нет.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Лобанов Игорь, Вы писали:
ЛИ>>А Вы используйте правильные кэши, которые дружат с кластером.
K>И где эти кэши будут физически находиться? На одной из нод кластера — слабая надёжность, на отдельной ноде — тоже слабо... Так где?
Есть разные варианты:
1) Самый простой: кэш локален на каждом узле, согласованность обеспечивается синхронной инвалидацией;
2) Для кэша используются отдельные специализированные узлы. Это стандартное решение для создания высоконагруженных приложений на платформе LAMP+memcached;
3) Самый сложный: данные в кэше автоматически реплицируются и балансируются между узлами, что обеспечивает высокую надёжность. Ключевые слова: consistent hashing, in-memory data grid, cache partitioning. Сейчас (по крайней мере в JEE) такое умеют только дорогие проприетарные продукты типа Oracle Coherence, но на подходе и open source альтернативы.
Здравствуйте, meowth, Вы писали:
G>>>>>>Только для этого надо поднять в память сначала весь объект. А это может быть непозволительно долго. M>>>>>Весь не надо, есть проекции и срезы. Кроме того, инфраструктура обеспечивает совершенно прозрачный для бизнес-скрипта кэш объектов. G>>>>Да ну? И как делать проекции и срезы с domain model? А в кеш не полностью объекты тянутся? M>>>Очень просто. Читайте NHibernate API и справочник по HQL. Читайте там, я уже писал, что в кеше лежат "т.н. deghydrated objects", разобранные на данные. Тянутся так, как вы напишете. G>>И как тогда domain-объекты с неполными данными работают? G>>То что технически такая возможность есть я не сомневаюсь. M>Во-первых, очень хорошо, что вы не спорите, что есть такая техническая возможность M>Во-вторых, вы что-путаете. Что значит -- "с неполными данными"? В anemic как-то по-другому данные в коде оказываются, без запроса к БД?
Я про другое спрашивал. На что мапится результат выборки? На какие domain objects? Как потом эти данные обрабатываются?
G>>>>Ну а как же domain model? Что там поймет domain expert? G>>>>Или снова получается что самая rich модель является таковой процентов на 5-10? M>>>Не заметил противоречий. В HQL аггрегаты поддерживаются наравне с domain query, для domain expert никакой разницы не наблюдается. M>>>Пример: M>>>"from SomeItems as si select si, count(si.children)".List(); G>>И какого типа объекты получатся? Это будут domain objects? Как потом логику применять к результатам такого запроса? M>Того типа, в который вы сконвертите. Ну если вы просили аггрегаты показать, значит, есть такой domain объект, в котором представим аггрегат. Логику применять -- как обычно.
А если нет? Например есть заказ. У него есть позиции. В одном случае надо получить заказ с суммой, в другом сумма нафиг не нужна, а в третьем вовсе надо сгруппировать по месяцам и суммы получить.
А в предметной области есть только "заказ" и все.
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Лобанов Игорь, Вы писали:
ЛИ>>>В случае же, когда нас интересует только один аспект Работника, механизм lazy loading гарантирует нам, что "лишние" данные вообще не будут фигурировать в операции.
G>>Очень наивно так полагать. G>>Я один раз исправлял один тормзящий код. Тормоза были именно из-за LL. Когда посмотрел профайлером оказалось что на простую на вид операцию к базе шло около сотни запросов. G>>Посмотрел внутренности, оказалось что в безобидном на вид методе (типа AddItem) было обращение к дочерней коллекции, которая подтягивалась лениво. G>>А так как был зайдействован Linq2SQL, то он тянул всю коллекцию связнынх объектов на каждое обращение. И метод этот вызывался в цикле. G>>Отключение LL и загрузка только нужных данных дала офигенный прирост производительности. Для этого понадобилость только 3 строчки написать.
M>Имхо вы тут путаетесь. Как LL может повлиять на то, что в цикле будут вытягиваться лишние данные? Как он может повлиять на то, что по каждому обращению данные будут вытягиваться заново из БД (объектный 2хуровневый кеш таки рулит(? M>ИМХО то, что linq2sql не дает настроить batch size loading в LL еще не значит, что LL -- это плохо и тормозно.
Еще раз если не заметили: проблема была исправлена тремя строчками с указанием явной загрузки нужных данных. Без двухуровневых объектных кешей и прочей лабуды.
Кстати как кеш обеспечивает когерентность в условиях работы нескольких приложений с одной базой (без общего кеша)? или просто при использовании ХП?
Здравствуйте, Лобанов Игорь, Вы писали:
ЛИ>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Лобанов Игорь, Вы писали:
ЛИ>>>В случае же, когда нас интересует только один аспект Работника, механизм lazy loading гарантирует нам, что "лишние" данные вообще не будут фигурировать в операции.
G>>Очень наивно так полагать.
ЛИ>Я всё же предлагаю разделять случаи, когда "должно, но не работает" и "в принципе не должно". Первое лечится багфиксингом, второе -- нет.
Здравствуйте, gandjustas, Вы писали:
M>>Во-вторых, вы что-путаете. Что значит -- "с неполными данными"? В anemic как-то по-другому данные в коде оказываются, без запроса к БД? G>Я про другое спрашивал. На что мапится результат выборки? На какие domain objects? Как потом эти данные обрабатываются?
Хм, надеюсь, я понял вас правильно. Результат выборки мапится на объект, которому потребовался срез. Чаще всего это UI DTO или Reporting DTO, или просто plain data (в этом случае никуда не мапится).
M>>Того типа, в который вы сконвертите. Ну если вы просили аггрегаты показать, значит, есть такой domain объект, в котором представим аггрегат. Логику применять -- как обычно. G>А если нет? Например есть заказ. У него есть позиции. В одном случае надо получить заказ с суммой, в другом сумма нафиг не нужна, а в третьем вовсе надо сгруппировать по месяцам и суммы получить. G>А в предметной области есть только "заказ" и все.
А если нет -- зачем вам аггрегат, если он заведомо не нужен?
Те примеры, что вы привели, похожи на reporting. Выборка маппится на reporting items (dto), которые потом отдаются -- клиенту или UI.
Давайте я поясню, что ли по двум этим вопросам. Мне кажется, я понял, что вы хотите уточнить. Вы опасаетесь, что rich тянет много из БД -- вместо отдельных полей подтягивает весь объект и т.д. Такое в целом имеет место быть -- при использовании rich запросы получаются тяжелее (тянут больше данных), но на практике опасения не оправдываются по следующим причинам:
0) выборка 2х полей осуществляется практически с той же скоростью, что и выборка 20 (проверено на практике);
1) за счет объектного кеша такие запросы становятся крайне редки, потому что все данные уже тут;
2) правильно настроенный LL и прочая инфраструктура позволяет минимизировать обращения к БД;
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
M>Хм, надеюсь, я понял вас правильно. Результат выборки мапится на объект, которому потребовался срез. Чаще всего это UI DTO или Reporting DTO, или просто plain data (в этом случае никуда не мапится).
M>Те примеры, что вы привели, похожи на reporting. Выборка маппится на reporting items (dto), которые потом отдаются -- клиенту или UI.
Ну где же тут rich?
M>Давайте я поясню, что ли по двум этим вопросам. Мне кажется, я понял, что вы хотите уточнить. Вы опасаетесь, что rich тянет много из БД -- вместо отдельных полей подтягивает весь объект и т.д. Такое в целом имеет место быть -- при использовании rich запросы получаются тяжелее (тянут больше данных), но на практике опасения не оправдываются по следующим причинам: M>0) выборка 2х полей осуществляется практически с той же скоростью, что и выборка 20 (проверено на практике);
Ну это смотря какие поля. Если джойнится несколько таблиц, то там может быть гораздо больше полей, чем 20. Если нужны только два из них остальные тянуть не стоит. Особенно по сети.
M>1) за счет объектного кеша такие запросы становятся крайне редки, потому что все данные уже тут; M>2) правильно настроенный LL и прочая инфраструктура позволяет минимизировать обращения к БД;
Зачем создавать проблемы, а потом их геройски решать с помощью объектных кешей, и настройки LL, если можно просто получить необходимые данные сразу?
А уж если база действительно начнет загибаться, то кешировать результаты выборки, а еще лучше кешировать presentation entities или ответ на клиенте.
Здравствуйте, gandjustas, Вы писали:
G>>>Посмотрел внутренности, оказалось что в безобидном на вид методе (типа AddItem) было обращение к дочерней коллекции, которая подтягивалась лениво. G>>>А так как был зайдействован Linq2SQL, то он тянул всю коллекцию связнынх объектов на каждое обращение. И метод этот вызывался в цикле. G>>>Отключение LL и загрузка только нужных данных дала офигенный прирост производительности. Для этого понадобилость только 3 строчки написать.
M>>Имхо вы тут путаетесь. Как LL может повлиять на то, что в цикле будут вытягиваться лишние данные? Как он может повлиять на то, что по каждому обращению данные будут вытягиваться заново из БД (объектный 2хуровневый кеш таки рулит(? M>>ИМХО то, что linq2sql не дает настроить batch size loading в LL еще не значит, что LL -- это плохо и тормозно.
G>Еще раз если не заметили: проблема была исправлена тремя строчками с указанием явной загрузки нужных данных. Без двухуровневых объектных кешей и прочей лабуды.
А может, тогда на ассемблер всем, а?
В вашей ситуации, естественно, надо было выбирать исправление по обстоятельствам, что вы и сделали.
G>Кстати как кеш обеспечивает когерентность в условиях работы нескольких приложений с одной базой (без общего кеша)? или просто при использовании ХП?
Подмножеством методов, используемых в случае распределенного кеша: инвалидация кеша (полуавтоматическая, по таймауту или оповещениям с БД), маркировка областей кеша.
В целом, при работе нескольких приложений (кластер как частный случай) с одной БД следует использовать общий распределенный кеш, чтобы не настраивать вручную параметры инвалидации кеша во избежание "заезда" в регион устаревших данных.
Здравствуйте, gandjustas, Вы писали:
M>>1) за счет объектного кеша такие запросы становятся крайне редки, потому что все данные уже тут; M>>2) правильно настроенный LL и прочая инфраструктура позволяет минимизировать обращения к БД; G>Зачем создавать проблемы, а потом их геройски решать с помощью объектных кешей, и настройки LL, если можно просто получить необходимые данные сразу? G>А уж если база действительно начнет загибаться, то кешировать результаты выборки, а еще лучше кешировать presentation entities или ответ на клиенте.
Это тоже у нас кешируется, не переживайте -- и результаты выборки (cached query в NHibernate), и ответ на клиенте и для клиента. Другое дело, что последние к инфраструктуре persistence не относятся.
Здравствуйте, gandjustas, Вы писали:
G>Ну это получится сервис в терминах anemic — класс содержащий логику обработки данных, и не содержащий самих данных.
Это будет не сервис в каких бы то ни было терминах. Это будет класс, представляющий собой ту или иную вполне предметную абстракцию. Вместо Товар.ПолучитьСкидку() имеем сущности Товар и Скидка — и так далее.
G>А если детально проанализировать предметную область, то окажется что очень мало объектов на самом деле обладают поведением.
Если в твоей предметной области мало объектов, которые обладают поведением, то значит жирная модель тебе не нужна. А вот в моей предметной области таких объектов много.
ВВ>>>>А если организацию при создании параметризировать сервисом, вызов в который она будет делегировать для получения списка емплоееров? G>>>Это будет уже идиотизм. Так как сущности окажутся привязаны к сервисам без необходимости. А в остальном код такой же как в anemic будет.
ВВ>>Вот когда придет понимание, что привязка сущностей к сервисам куда лучше лучше чем зависимость сервисов от контрактов сущностей — что противоречит даже большинству сервис-ориентед паттернов — тогда и станет понятно, чем хороша жирная модель.
G>Давай в коде. G>ты предлагаешшь:
Я предлагаю:
— размещать в классах только ту логику, которая непосредственно завязана на эти классы, которая является, скажем так, сущностной характеристикой класса. Будет ли эта логика прописана непосредственно в методах класса или во внешнем классе — вообще без разницы.
— не размещать в классах логику доступа к данным. Для этого существует упоминавшаяся выше инфраструктура (или Репозиторий у Фаулера). Кстати, приведенный тобой пример как раз очень даже напоминает работу с репозиторием.
G>В моем связность меньше. При этом еще код repository проще будет. G>Что не так?
1. Код репозитория будет одинаков в обоих случах вообще-то
2. Связности меньше между чем и чем? Ты серьезно считаешь, что заменив вполне логичное Организация.ПолучитьСотрудников на ПолучитьСотрудников(Организация) ты решил какую-то серьезную проблему?
Ну давай разберемся.
Положим, у нас есть некий сервис, возвращающий сотрудников. Что еще делает этот сервис? Согласно каким принципам мы будем группировать функции в сервисы?
Далее — этот сервис зависит от внешних метаданных. Что уже плохо само по себе. Если мы не хотим помимо этого получить еще и кучу внешних зависимостей от других сервисов — что уже совсем как-то странно — нам придется все-все-все, что хоть как-то связано с сотрудниками и организациями (а может быть еще и с ролями, и с департаментами и пр.) — запихать в один сервис. А приложение у нас — ну скажем, орг-структура. Т.е. фактически вся логика в одном сервисе. Ну нормально.
Далее — нужно добавить новый метод — ПолучитьМенеджеров или что-то в этом роде, неважно. Что мы делаем? Дописываем новый метод в сервис? Ну это тоже совсем уж странно как-то. Умные люди говорят — надо новый сервис делать. Хорошо — новый так новый. Через неделю еще пару методов. Опять новый сервис?
Пять лет наша система поработала. На что она похожа через пять лет? Правильно. Зажимаем нос, проходим дальше.
И это банальный в общем-то пример. Орг-структура какая-то. А как быть с системами, в которых тысячи бизнес-сущностей. Вполне из жизни, кстати. Вот есть некоторая организация, которая собирает статистические данные — причем они у нее начинаются с уровня Государства и кончаются уровнем... Комната. Таким же макаром будем сервисы лепить?
В итоге — мне честно уже неясно — а ради чего все это? Ну выделили логику в сервис, ну отлично, а дальше что? Делаем вид, что убрали зависимости. По-моему наоборот — потенциально зависимости усилили. И на кой этот сервис в таком виде-то? Нормальный паттерн — тот же СОА — на таких сервисах не построишь. Полиморфизм идет лесом. Так смысл?
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>>>Посмотрел внутренности, оказалось что в безобидном на вид методе (типа AddItem) было обращение к дочерней коллекции, которая подтягивалась лениво. G>>>>А так как был зайдействован Linq2SQL, то он тянул всю коллекцию связнынх объектов на каждое обращение. И метод этот вызывался в цикле. G>>>>Отключение LL и загрузка только нужных данных дала офигенный прирост производительности. Для этого понадобилость только 3 строчки написать.
M>>>Имхо вы тут путаетесь. Как LL может повлиять на то, что в цикле будут вытягиваться лишние данные? Как он может повлиять на то, что по каждому обращению данные будут вытягиваться заново из БД (объектный 2хуровневый кеш таки рулит(? M>>>ИМХО то, что linq2sql не дает настроить batch size loading в LL еще не значит, что LL -- это плохо и тормозно.
G>>Еще раз если не заметили: проблема была исправлена тремя строчками с указанием явной загрузки нужных данных. Без двухуровневых объектных кешей и прочей лабуды. M>А может, тогда на ассемблер всем, а?
Причем тут это?
M>В вашей ситуации, естественно, надо было выбирать исправление по обстоятельствам, что вы и сделали.
Ну так если весь код так писать он получится и быстрым и без огромного кеша.
G>>Кстати как кеш обеспечивает когерентность в условиях работы нескольких приложений с одной базой (без общего кеша)? или просто при использовании ХП? M>Подмножеством методов, используемых в случае распределенного кеша: инвалидация кеша (полуавтоматическая, по таймауту или оповещениям с БД), маркировка областей кеша. M>В целом, при работе нескольких приложений (кластер как частный случай) с одной БД следует использовать общий распределенный кеш, чтобы не настраивать вручную параметры инвалидации кеша во избежание "заезда" в регион устаревших данных.
То есть предлагаете вместе с БД держать еще клатер для кеша? Очень круто.
. Насколько я знаю да, штатный NLB из 2008 винды.
