Здравствуйте, <Аноним>, Вы писали:
А> А как думаешь, если сделать нормальную очистку кэша: всегда удалять все объекты, на которые больше никто не ссылается, и соответственно, обновлять только те объкты, которые реально требуются (то есть, если у пользователя нет ни одного объекта типа "Employee", то и не загружать изменения, связанные с этим типом. Или, если изменяемый объект не попадает под фильтры, то аналогично.) жизненно будет использовать на больших проектах такой подход?
В принципе — да. Я бы сделал примерно так:
1. Поделил бы весь UI на списки объектов, и формы редактирования одного объекта
2. В кэше бы держал объекты, видимые в настоящий момент в UI.
3. Дополнительно бы рассмотрел вопрос о помещении в кэш справочников, на которые ссылаются объекты, открытые на редактирование
4. Сбрасывал бы кэш при закрытии соответствующих окон.
5. Регистрировал бы наблюдаемые списки и отдельные объекты на сервере, чтобы сервер рассылал уведомления об изменениях.

Мораль: слишком много списков одновременно не откроют, поэтому потребный размер кэша ограничен.

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

S>Здравствуйте, <Аноним>, Вы писали:
А>> А как думаешь, если сделать нормальную очистку кэша: всегда удалять все объекты, на которые больше никто не ссылается, и соответственно, обновлять только те объкты, которые реально требуются (то есть, если у пользователя нет ни одного объекта типа "Employee", то и не загружать изменения, связанные с этим типом. Или, если изменяемый объект не попадает под фильтры, то аналогично.) жизненно будет использовать на больших проектах такой подход?
S>В принципе — да. Я бы сделал примерно так:
S>1. Поделил бы весь UI на списки объектов, и формы редактирования одного объекта
S>2. В кэше бы держал объекты, видимые в настоящий момент в UI.
S>3. Дополнительно бы рассмотрел вопрос о помещении в кэш справочников, на которые ссылаются объекты, открытые на редактирование
S>4. Сбрасывал бы кэш при закрытии соответствующих окон.
S>5. Регистрировал бы наблюдаемые списки и отдельные объекты на сервере, чтобы сервер рассылал уведомления об изменениях.

S>Мораль: слишком много списков одновременно не откроют, поэтому потребный размер кэша ограничен.

Спасибо большое за помощь.

Здравствуйте, Аноним, Вы писали:

>>Я же говорю: мы делали ровно такую систему. Проблема — в том, что рассылка изменений всем клиентам стоит очень дорого.

Нормально все работает. Сложно сказать почему не работало у Синклера, но пример налицо — система с кешированием бизнес объектов написана, протестирована и проверена в пилот проекте.

Более того — некоторые бизнес объекты очень желательно держать в памяти.
Другое дело — не нужно бизнес объекты ЛЮБОГО класса там держать.

У Фаулера очень внятно все описано, кстати. У нас получилось, что сначала сделали, потом книга Фаулера появилась. Мы сидели, читали и восхищались — ах какой умный мужик, сделал совсем как мы! )

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

UMA>Здравствуйте, Аноним, Вы писали:

>>>Я же говорю: мы делали ровно такую систему. Проблема — в том, что рассылка изменений всем клиентам стоит очень дорого.

UMA>Нормально все работает. Сложно сказать почему не работало у Синклера, но пример налицо — система с кешированием бизнес объектов написана, протестирована и проверена в пилот проекте.

UMA>Более того — некоторые бизнес объекты очень желательно держать в памяти.
UMA>Другое дело — не нужно бизнес объекты ЛЮБОГО класса там держать.

UMA>У Фаулера очень внятно все описано, кстати. У нас получилось, что сначала сделали, потом книга Фаулера появилась. Мы сидели, читали и восхищались — ах какой умный мужик, сделал совсем как мы! )

А как именно называется эта книга Фаулера?

Здравствуйте, Аноним, Вы писали:

А> А как именно называется эта книга Фаулера?

Архитектура корпоративных приложений, конечно

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

UMA>Нормально все работает. Сложно сказать почему не работало у Синклера, но пример налицо — система с кешированием бизнес объектов написана, протестирована и проверена в пилот проекте.
Ну почему же не работало? Работало. Но работало плохо — с течением времени забивался кэш, всё начинало тормозить и приходилось перезапускать приложение. Производительность была раз примерно в 10 ниже, чем теоретически достижимая для данного случая. Ошибку в счетчике ссылок мы чинили около полугода. Были тяжелые проблемы с апдейтом схемы.

UMA>Более того — некоторые бизнес объекты очень желательно держать в памяти.
Смотря где эта память

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

S>Работало. Но работало плохо — с течением времени забивался кэш, всё начинало тормозить и приходилось перезапускать приложение
S>Производительность была раз примерно в 10 ниже, чем теоретически достижимая для данного случая. Ошибку в счетчике ссылок мы чинили около полугода.

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

Здравствуйте, UrryMcA, Вы писали:
UMA>А можно поподробнее?
Про что?
UMA>У меня сложилось впечатление, что в силу специфики обрабатываемых данных я не вижу проблем, которые могут возникнуть.
UMA>У меня большие сомнения, что подобные проблемы нельзя решить кардинально.
Кардинально — можно. Получится Hibernate.