Hello, Ivan!
You wrote on Mon, 20 Aug 2007 11:58:10 GMT:
ID> Возможно, кто-то встречался с интересными паттернами или просто ID> поделится опытом — где лучше всего решать проблемы синхронизации ID> в сервере приложений?
Здравствуйте, Ivan Danilov, Вы писали:
ID>Возможно, кто-то встречался с интересными паттернами или просто поделится опытом — где лучше всего решать проблемы синхронизации в сервере приложений?
ID>Можно линк на статью/best practices etc.
Можно рассмотреть ActiveObject или instance-per-request (SingleCall в remoting или IHttpHandler в веб приложениях).
Какие именно проблемы синхронизации вы хотите решить?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Можно рассмотреть ActiveObject или instance-per-request (SingleCall в remoting или IHttpHandler в веб приложениях).
TK>Какие именно проблемы синхронизации вы хотите решить?
Собственно, классы, взаимодействующие с клиентом являются Stateless. А вот под ними лежат контроллеры, которые работают с business entities и используют хранилища.
Соответственно, основная проблема — куда засунуть код, контролирующий целостность данных (т.е. предотвращающих запись и запись/чтение одновременно), чтобы он не торчал из всех дыр в приложении. Как его централизовать, что-ли?
Здравствуйте, Ivan Danilov, Вы писали:
TK>>Какие именно проблемы синхронизации вы хотите решить? ID>Собственно, классы, взаимодействующие с клиентом являются Stateless. А вот под ними лежат контроллеры, которые работают с business entities и используют хранилища.
ID>Соответственно, основная проблема — куда засунуть код, контролирующий целостность данных (т.е. предотвращающих запись и запись/чтение одновременно), чтобы он не торчал из всех дыр в приложении. Как его централизовать, что-ли?
А нельзя переложить все эти concurrency заботы на хранилища данных? Если на хранилища данных это переложить нельзя, то можно применить АОП и полностью отделить логику доступа от логики контроля.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>А нельзя переложить все эти concurrency заботы на хранилища данных? Если на хранилища данных это переложить нельзя, то можно применить АОП и полностью отделить логику доступа от логики контроля.
В принципе, на хранилища переложить можно. Немного, правда, боюсь дедлока, который на таком низком уровне отследить не удастся никак. Простейший способ синхронизации — использование ключевого слова lock на хранилище, но при дедлоке он просто повесит весь сервер Что, по понятным причинам, не есть гуд. Да и производительность оставит желать лучшего.
Что касается Аспект-оринетированного программирования — кроме названия, я о нем не знаю ничего Буду гуглить.
ID> Простейший способ синхронизации — использование ключевого слова lock на хранилище
Был неправ, он вообще ничем не помогает. Объекты-то могут быть уже получены другим потоком. Лочить business entities? Их же тысячами используют... Повесится
Здравствуйте, Ivan Danilov, Вы писали:
ID>В принципе, на хранилища переложить можно. Немного, правда, боюсь дедлока, который на таком низком уровне отследить не удастся никак. Простейший способ синхронизации — использование ключевого слова lock на хранилище, но при дедлоке он просто повесит весь сервер Что, по понятным причинам, не есть гуд. Да и производительность оставит желать лучшего.
т.е. хранилище это нечто самопальное, а не готовая БД с поддержкой техже транзакций?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Ivan Danilov, Вы писали:
ID>Был неправ, он вообще ничем не помогает. Объекты-то могут быть уже получены другим потоком. Лочить business entities? Их же тысячами используют... Повесится
Если хранилище "свое собственное" то наверное, мало чего остается... с другой стороны, если блокировка есть только на чтение/запись — это может быть не так сложно...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Ivan Danilov, Вы писали:
ID>> БД присутствует. FireBird 1.5. IB>Ну вот пусть этим FB и занимается. Получится проще, надежнее и быстрее.
Здравствуйте, Ivan Danilov, Вы писали:
ID>>> БД присутствует. FireBird 1.5. IB>>Ну вот пусть этим FB и занимается. Получится проще, надежнее и быстрее.
ID>Хм. А кэшированные данные как охранять?
Тут можно определиться с тем, насколько критичными являются кешированные данные. В каких-то случаях, может оказаться достаточным просто сбросить закешированное значение при его изменении. для каких-то, можно завести специальную табличку в FB для отслеживания блокировок...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Ivan Danilov, Вы писали:
ID>Возможно, кто-то встречался с интересными паттернами или просто поделится опытом — где лучше всего решать проблемы синхронизации в сервере приложений?
Лучше всего их не решать. Т.е. стараться до последнего синхронизации избежать.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Ivan Danilov, Вы писали:
ID>>Возможно, кто-то встречался с интересными паттернами или просто поделится опытом — где лучше всего решать проблемы синхронизации в сервере приложений?
AVK>Лучше всего их не решать. Т.е. стараться до последнего синхронизации избежать.
Как можно их избежать? В любом случае несколько потоков будут работать с одними и теми же данными. Я себе с трудом представляю другой вариант...
Здравствуйте, Ivan Danilov, Вы писали:
ID>Хм. А кэшированные данные как охранять?
Во-первых, заниматься кешированием в рукопашную, только после того как стало понятно, что есть узкое место и оно лечится кешированием.
А во-вторых — не охранять, а просто грохать при поступлении новых данных.
Что, по понятным причинам, не есть гуд. Да и производительность оставит желать лучшего.
Буду гуглить. 
Мы уже победили, просто это еще не так заметно...
