Здравствуйте, GlebZ, Вы писали:
S>>Как "так"? Не делать DTO отличными от БО? GZ>Для прикладника, зачем?
А какой изначальный смысл у DTO? Я всегда думал, что это не только объекты для передачи данных по сети, но в конечном счете DTO — это то с чем работает подсистема клиента. Ведь фактически в виде DTO данные приходят на клиент. А вдруг прикладная программа захочет показать (передать на клиент) информацию такой структуры, какого бизнес объекта и нет. Какую-нибудь сводную таблицу?
А вообще гораздо более интересный вопрос — это как сделать так, чтобы прикладная программа работала только на сервере приложений, а на клиенте находилось нечто, чем можно было-бы управлять с сервера и что не требовало бы наличия VM на клиенте. А по функциональности, желательно, чтобы это нечто приближалось к обычному оконному GUI.
Уж больно заманчивая эта идея с точки зрения прикладных программистов: все программы на сервере в единой среде.
Мдяяя. Я вижу Вы Oracle больше теоретически знаете (да и то неправильно). Ну давай на примере:
Делаем таблицу так:
create table ST (
x number,
y number
)
/
insert into ST values (1, 2)
/
insert into ST values (3, 4)
/
commit
А тепеь открываем два соединения и делаем следующее (в той последовательности, как написано):
Соединение1:
set transaction isolation level SERIALIZABLE
/
select * from ST /* Типа прочитали данные в сериализованной транзакции,
по твоему они должны были заблокироваться! */
Соединение2:
update ST set y = 10 /* Думаешь здесь будет ошибка или соединение повиснет,
фигушки, все сработает! */
/
commit/* И это сработает */
Соединение1:
select * from ST /* Читаем еще раз в той же транзакции, т.к. соединение1 ни
коммита ни роллбака не делало.
И получаем следующий набор данных:
*X* *Y*
1 2
3 4
т.е. не видим подтвержденных соединением2 данных,
т.е. транзакция на самом деле сериализованная. */
/
commit/* Ну и это не вызовет никаких ошибок. */
Не веришь — проверь сам!
Вот еще, первое что нашел, может где-то есть развернутее: Из Oracle 8i Concepts:
Because Oracle does not use read locks in either read-consistent or serializable
transactions, data read by one transaction can be overwritten by another...
А вот еще один веселенький примерчик. Для глбины понимания, так сказать :
Делаем таблицу так же:
create table ST (
x number,
y number
)
/
insert into ST values (1, 2)
/
insert into ST values (3, 4)
/
commit
А тепеь открываем два соединения и делаем следующее (в той последовательности, как написано):
Соединение1:
set transaction isolation level SERIALIZABLE /* Начинаем транзакцию до update'а во втором соединении.
Это важно. */
Соединение2:
set transaction isolation level SERIALIZABLE
/
update ST set y = y + 1 /* Пройдет нормально */
Соединение1:
update ST set y = y + 1 /* Повесится до окончания транзакции в Соединении2 */
Соединение2:
commit/* Пройдет нормально */
Здесь Соединение1 перестанет висеть и самое интересное, что тот оператор update, на котором оно висело выдаст ошибку ORA-08177.
ORA-08177 can't serialize access for this transaction
Cause: Encountered data changed by an operation that occurred after the start
of this serializable transaction.
Action: In read/write transactions, retry the intended operation or transaction.
S>Because Oracle does not use read locks in either read-consistent or serializable
S>transactions, data read by one transaction can be overwritten by another...
Б@@@,Б@@@,Б@@@
Чего-то я такого не ожидал от Oracle. Как раз то, о чем говорит Merle на каждом углу. Oracle сериальные транзакции отнюдь не serialize. Блин. Они не дают упорядоченного графика. Я никогда не использовал их, и сам додумал до нормального уровня. Не думал что так погано. Сериализованными они становятся только с ручной работой.
Итак, данные транзакции, если не использовать for update — отличаются только тем,
что более поздний update ты никогда не запишешь. Ну не могли как-то по другому обозвать.
Что мы получаем в результате. Возьмем твою таблицу.
create table ST (
x number,
y number
)
/
insert into ST values (1, 2)
/
insert into ST values (3, 4)
/
commit
Соединение1:
set transaction isolation level SERIALIZABLE
/
select y from ST where x=1;
выполняем на уровне бизнес-логики y=y+1, и запишем в y который стал 3 в строку где x=3
update st set y=3 where x=3;
Соединение2:
set transaction isolation level SERIALIZABLE
/
select y from ST where x=3;
выполняем на уровне бизнес-логики y=y-1, и запишем в y который стал 3 в строку где x=1
update st set y=3 where x=1;
Соединение1:
commit;
Соединение2:
commit;
В результате получаем результат, где везде y=3. То есть в результате ни та, ни другая транзакция своего не добилась. Обломс. И таких ситуаций можно придумать кучу. Потому как без блокировок на чтение или хотя бы таймстампы на чтение, согласованных данных не получишь.
S>Здесь Соединение1 перестанет висеть и самое интересное, что тот оператор update, на котором оно висело выдаст ошибку ORA-08177.
S>
S>ORA-08177 can't serialize access for this transaction
S>Cause: Encountered data changed by an operation that occurred after the start
S>of this serializable transaction.
S>Action: In read/write transactions, retry the intended operation or transaction.
Хоть это нормально. Они по таймстемпу отбивают. В условиях когда невозможно подождать окончание конкурирующей транзакции, они отбивают транзакцию. Хоть какой-то бальзам на душу. Хотя в условиях блокировок на чтение, можно было бы ожидать выполнения конкурирующей транзакции, и после этого изменять.
Здравствуйте, GlebZ, Вы писали:
GZ>Итак, данные транзакции, если не использовать for update — отличаются только тем, GZ>что более поздний update ты никогда не запишешь. Ну не могли как-то по другому обозвать.
Нет. Главное тем, что ты не видишь подтвержденных изменений других транзакций. Это очень удобно.
GZ><skiped...> GZ>В результате получаем результат, где везде y=3. То есть в результате ни та, ни другая транзакция своего не добилась. Обломс. И таких ситуаций можно придумать кучу. Потому как без блокировок на чтение или хотя бы таймстампы на чтение, согласованных данных не получишь.
Это как раз и есть Б@@@,Б@@@,Б@@@ . Но, это все равно лучше, чем read committed! Потому-что написать твой же пример правильно в read committed транзакциях тоже проблема.
Вообщем я выбрал такой режим как режим по умолчанию для framework'а. В отдельных ситуациях прикладная программа может накладывать блокировки явно, если есть необходимость.
У него ИМХО больше преимуществ, чем у какого-либо другого. Ты так не считаешь, — приведи лучший режим.
Здравствуйте, stalcer, Вы писали:
S>Ладно. Я все поскипал, а то мы уже отвлеклись от главного вопроса.
Согласен.
S>Решение которое я предлагаю — это ведь не только кэш второго уровня. Это некая система, в которой каждый из компонентов важен. И только все вместе они будут работать. Так что предлагаю не натягивать мою архитектуру на стандартные подходы (типа statefull или stateless), а постараться понять ее в целом — как систему взаимосвязанных идей.
Честно говоря, мне это нравится. Я никогда не видел сложных и при этом "чистых" statefull или stateless моделей.
Все лишнее поскипаю. Либо я с этим согласен, либо оно как-то связано с другими предложениями.
S>Итак, что я хочу сделать (читай — исходные требования к функциональности):
S>- Система должна обеспечивать навигационный доступ и механизм запросов.
Маленький вопрос. В какой степени поддерживается навигационный доступ. Точнее, будет ли он работать по сети?
S>- Я нигде не упоминал ни про какие кэши, так как они являются лишь средством оптимизации и ни в коем случае не должны менять логику работы.
Было бы хорошо S>- Однако уровень изоляции был выбран именно такой, для простоты реализации кэшей. При другом уровне изоляции, например, read committed, реализация была бы более сложной и производительность могла бы оказаться практически неприемлимой.
Как это не странно звучит, но в данной системе реализация read committed была бы сложней. S>- Но, такой уровень изоляции имхо удобен и для прикладных программистов.
Честно говоря, согласно бизнес логике более важно понятие оптимистической и пессимистической транзакции. То есть, может ли юзер (а прикладному программисту надо эту ситуацию обрабатывать) получить отлуп по транзакции. Или он при загрузке какой-то формы (то есть открытии некоторой бизнес-транзакции) должен получить сообщение что данный объект редактируется таким-то таким, и пока не стоит его редактировать. Стандартная реализация БД транзакций — по умолчанию такого не дает. То есть, надо прописать — либо мы не будет никогда работать с пессимистической транзакцией, либо дать инструменты для из организации. Если второй вариант — напишу несколько неприятных проблем(с которыми сам встретился). К сожалению, если в проектах которых я участвовал нужен был транзакционный механизм, ни разу не пришлось ограничиваться оптимистическими. Постановщики излишне пессимистичны.
S>Например, перед выполнением OQL запроса, использующего SQL запросы БД.
OQL — это я люблю
S>- Вообще, какие-либо объекты из сессионного кэша могут быть удалены в любой момент (учитывая ограничение предыдущего пункта). Т.е. на протяжении транзакции они могут быть несколько раз прочитаны и удалены. Работает обычный алгоритм LRU или MRU. Т.е. транзакция сама по себе не держит объекты в кэше.
Хотелось бы в данном случае сказать. Скорее всегоIMHO, вероятность что будет обращение к измененным объектам — несколько выше, чем к остальным. Во вторых, непонятно все-таки из контекста, после транзакции практически все объекты в кэше становится невалидными?
S>Хранимые аттрибуты отличаются от простых полей тем, что они транзакционны. Т.е. даже если объект не был удален из кэша по завершению транзакции, состояние его хранимых аттрибутов будет правильным по отношению к следующей транзакции (он попросту перечитает свое состояние из БД, при необходимости).
Может ли объект хранить другие аттрибуты, которые зависят от транзакционных?
S>Исходя из этого каждой транзакции я присваиваю номер (просто автоинкрементный, но в пределах сесиии, т.е. он локальный и нигде не сохраняемый). И в заголовке объекта, также хранится номер. При обращении к аттрибуту (как на чтение так и на запись) значения этих номеров сравниваются. Если они одинаковы — объект уже был подгружен в течении этой транзакции, если разные — объект подгружается и номер в заголовке изменяется на текущий. При таком подходе при откате или подтверждении транзакции достаточно просто увеличить одну переменную "номер текущей транзакции" на единицу. Даже по кэшированным объектам пробегать не нужно. ИМХО очень эффективно.
Здесь мне кажется, лучше пробежать. Ты занимаешь ресурсы — объектами которые уже никому никогда не понадобятся. И еще сразу вопрос: После отката транзакции — остаются или не остаются объекты DSL c ссылками. Если объект нельзя сбросить(перечитать) в случае отката (100% протухшие данные), то нужно что-то делать. Или я чего-то не усек.
S>И, на самый последок: Может быть эта архитектура и не оптимально производительна, но она абсолютно не противоречива. И вероятно более проста в понимании для прикладного программиста.
С удовольствием причитал месагу. Люблю нестандартные решения (правда по опыту знаю, что они постепенно приводятся к стандартизованному виду). Что касается непротиворечивости, то остался вопрос по пессимистическим транзакциям (будут или нет), масштабируемости БД и еще пожалуй, момент отката транзакций.
Извиняюсь забыл разъяснить про момент отката транзакций. Меня интересует вопрос: ты написал про savepoint когда объекты сбрасываются на БД. Как будет обрабатываться ошибка, если она произойдет при сбросе?
Здравствуйте, stalcer, Вы писали:
S>У него ИМХО больше преимуществ, чем у какого-либо другого. Ты так не считаешь, — приведи лучший режим.
К сожалению, я так как-раз и не считаю. Сразу скажу, буду иметь ввиду, что как принято в ведущих SQL базах — вероятность ролбека на несколько порядков ниже чем вероятность коммита.
1. Как я уже показал, протокол не гарантирует что база будет находиться в кошерном состоянии. Хотя вероятность подобного не велика, но риск несогласованной базы значительно криминальней чем бы то ни было. И это должно лечь на плечи прикладного программиста.
2. Если транзакция не прошла, то ее уже никакими средствами не пропихнешь. Это плохо. При этом состояние ожидание (что отобразится у пользователя зависшим состоянием) все равно остается (мне непонятно зачем его сделали, но если они это сделали значит были причины(например откат старшей транзакции)).
3. Можно в любой момент получить откат транзакции. Тоже хреново — потому что прогнозировать нельзя. При этом, вероятность такого на порядок выше чем при остальных типах транзакций.
4. Вероятность дедлока высока.
5. При длинных транзакциях, вероятность что пользователи будут падать и виснуть увеличивается в несколько раз.(а у тебя как раз бизнес-транзакция завязана на системную, то есть вероятность длинной транзакции увеличивается).
Единственный плюс подобных транзакций — отчеты удобно делать
Здравствуйте, stalcer, Вы писали:
S>А вообще гораздо более интересный вопрос — это как сделать так, чтобы прикладная программа работала только на сервере приложений, а на клиенте находилось нечто, чем можно было-бы управлять с сервера и что не требовало бы наличия VM на клиенте. А по функциональности, желательно, чтобы это нечто приближалось к обычному оконному GUI. S>Уж больно заманчивая эта идея с точки зрения прикладных программистов: все программы на сервере в единой среде.
Ты над Web-клиентом не думал?
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
S>>>Как "так"? Не делать DTO отличными от БО? GZ>>Для прикладника, зачем?
S>А какой изначальный смысл у DTO? Я всегда думал, что это не только объекты для передачи данных по сети, но в конечном счете DTO — это то с чем работает подсистема клиента. Ведь фактически в виде DTO данные приходят на клиент. А вдруг прикладная программа захочет показать (передать на клиент) информацию такой структуры, какого бизнес объекта и нет. Какую-нибудь сводную таблицу?
Почти. В некотором смысле возможен вариант — объекты конвертятся в DTO перед передачи и конвертятся в объекты после передачи. Притом в клиенте — объекты изменяют свою структуру в зависимости от задачи. Но в данном случае, для облегчения жизни прикладника — лучше объект унифицировать.(я так думаю).
S>А вообще гораздо более интересный вопрос — это как сделать так, чтобы прикладная программа работала только на сервере приложений, а на клиенте находилось нечто, чем можно было-бы управлять с сервера и что не требовало бы наличия VM на клиенте. А по функциональности, желательно, чтобы это нечто приближалось к обычному оконному GUI. S>Уж больно заманчивая эта идея с точки зрения прикладных программистов: все программы на сервере в единой среде.
Участвовал в разработке решения. В нем повторялась функциональность ASP сервера. На сервере скрипт в какой-то стрим. При встрече символов <% %> — выполнялось и результаты также в стрим. После этого все полученное выполнялось на клиенте. Практически — на клиента уходили только результаты и формы (все бизнес-логика находилась в <% %>, и выполнялась на сервере).
А не наличие VM — это Web-решение. Там VM поддерживается эксплорером.
Здравствуйте, Sinclair, Вы писали:
S>Ты над Web-клиентом не думал?
Дело не во том, в какой технологии это будет реализовано. Можно, например, и в Delphi написать набор компонентов, которые будут по сути тонким клиентом.
Просто у меня сомнения — не тупиковая ли это идея в принципе. Т.е. идея в том, чтобы написать клиент, заложив в него какую-либо стандартную функциональность (отображение менюшек, показ форм, и в них работа с данными, и т.п.), так чтобы не нужно было выполнять прикладные программы (т.е. некоторую их часть) на клиенте. Не будет ли все это тормозить.
По моему в таком сценарии получается некое противоречие между производительностью и функциональностью. А я именно и хочу написать свой клиент (не веб), чтобы это противоречие насколько возможно сгладить. Потому как требование к функциональности у меня несколько больше, чем веб. Хочу чтобы внешне было похоже, ну скажем, на 1С.
Здравствуйте, GlebZ, Вы писали:
GZ>А не наличие VM — это Web-решение. Там VM поддерживается эксплорером.
Сделать VM на клиенте — не проблема. Это просто геморрой для прикладника. Так как единого вычислительного пространства не получается. Например, нельзя же домен-объекты вместе с идентити мапом держать и на клиенте. В принципе, можно, конечно извратиться, но че-то не хочется.
Здравствуйте, GlebZ, Вы писали:
GZ>К сожалению, я так как-раз и не считаю. <поскипано>
Дык, приведи пример лучшего режима.
GZ>5. При длинных транзакциях, вероятность что пользователи будут падать и виснуть увеличивается в несколько раз.(а у тебя как раз бизнес-транзакция завязана на системную, то есть вероятность длинной транзакции увеличивается).
Для прикладного программиста "framework-транзакция" — это и есть системная! Из них он сам должен лепить бизнес транзакции. Просто я другого универсального решения не вижу.
Здравствуйте, stalcer, Вы писали:
S>Дело не во том, в какой технологии это будет реализовано.
Ну, не совсем. Любая технология накладывает некоторые ограничения. S>Можно, например, и в Delphi написать набор компонентов, которые будут по сути тонким клиентом. S>Просто у меня сомнения — не тупиковая ли это идея в принципе. Т.е. идея в том, чтобы написать клиент, заложив в него какую-либо стандартную функциональность (отображение менюшек, показ форм, и в них работа с данными, и т.п.), так чтобы не нужно было выполнять прикладные программы (т.е. некоторую их часть) на клиенте. Не будет ли все это тормозить.
Гм. А с чего бы ему тормозить? Web-приложения же не тормозят. S>По моему в таком сценарии получается некое противоречие между производительностью и функциональностью.
Зачем теоретизировать, когда есть практика? Посмотри, к примеру, на Exchange 2003 web access. Или на http://maps.google.com. S>А я именно и хочу написать свой клиент (не веб), чтобы это противоречие насколько возможно сгладить.
Ну, тогда возьми удачные черты от веб, и дополни тем, чего нет. S>Потому как требование к функциональности у меня несколько больше, чем веб.
Ты знаешь, я мало чего встречал такого, чтобы было заметно больше, чем веб. А если не заметно разницы, то зачем платить больше? (Конечно, я в курсе, что векторные интерфейсы от McSeem2 вряд ли удастся насколько-то близко воспроизвести в рамках HTML/CSS/JS) S>Хочу чтобы внешне было похоже, ну скажем, на 1С.
Извини, я с ней незнаком. А что там есть такого, чего нету в вебе? Ты не мог бы объяснить + скриншоты там прислать...
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Можно, например, и в Delphi написать набор компонентов, которые будут по сути тонким клиентом. S>>Просто у меня сомнения — не тупиковая ли это идея в принципе. Т.е. идея в том, чтобы написать клиент, заложив в него какую-либо стандартную функциональность (отображение менюшек, показ форм, и в них работа с данными, и т.п.), так чтобы не нужно было выполнять прикладные программы (т.е. некоторую их часть) на клиенте. Не будет ли все это тормозить.
S>Гм. А с чего бы ему тормозить? Web-приложения же не тормозят.
Ну не знаю. Зачем тогда делают язык на клиенте. Это же геморрой. Но все же делают. Видимо — тормозит.
S>Зачем теоретизировать, когда есть практика?
Ну потеоретизировать тоже полезно.
S>Посмотри, к примеру, на Exchange 2003 web access. Или на http://maps.google.com.
Посмотрю .
S>>Хочу чтобы внешне было похоже, ну скажем, на 1С. S>Извини, я с ней незнаком. А что там есть такого, чего нету в вебе? Ты не мог бы объяснить + скриншоты там прислать...
Ну, не знаю. Даже если сделать какой-нибудь грид, который будет данные по сети качать, т.е. если его специально для этого сделать, то наверное это будет производительней, чем HTML странички. Хотя бы за счет бинарной передачи данных, и т.п.
А хочу я, чтобы было похоже на WinForms клиент. Т.е. формочки в MDI, менюшки, панельки, ну и работа с данными — передача на клиент, чтоб не тормозила, сортировки там всякие, поиски, фильтры, кнопочки на формах и т.п.
Только без скриптов на клиенте .
Я больше склоняюсь в тому, что это все таки возможно сделать так, чтобы приемлимо производительно работало.
Здравствуйте, GlebZ, Вы писали:
GZ>Маленький вопрос. В какой степени поддерживается навигационный доступ. Точнее, будет ли он работать по сети?
Нафиг, нафиг. Не хочу по сети . Хочу чтобы вся программа выпонялась в одном месте (для этого и про клиент спрашиваю).
S>>- Однако уровень изоляции был выбран именно такой, для простоты реализации кэшей. При другом уровне изоляции, например, read committed, реализация была бы более сложной и производительность могла бы оказаться практически неприемлимой. GZ>Как это не странно звучит, но в данной системе реализация read committed была бы сложней.
Дык, и я про то же.
GZ>Может ли объект хранить другие аттрибуты, которые зависят от транзакционных?
Ну, никто не запрещает. Наверное это плохо. Я сам пока в сомнениях .
GZ>Здесь мне кажется, лучше пробежать. Ты занимаешь ресурсы — объектами которые уже никому никогда не понадобятся.
Хе. Доменный язык у меня — со сборшиком мусора (аля C#). И пока сборка мусора не пройдет — память фактически будет занята. Более того только сборщик мусора может сказать есть ли на объект ссылки или — нет. Поэтому, алгоритм удаления объектов из сессионного кэша тесно связан со сборкой мусора, и запускается как ее часть.
Таким образом получается, что фактически ресурсы зависят от периодичности сборки мусора, а не от периодичности транзакций.
GZ>И еще сразу вопрос: После отката транзакции — остаются или не остаются объекты DSL c ссылками.
В смысле, остаются ли ссылки на объекты, дык — это дело прикладного программиста. Хочет держать объект (хранить ссылку на него в глобальной переменной) — пусть держит. Может он его овигенно сложным расчетом выбрал (состояние полей — да могут поменяться, но объект выбирать будет уже не нужно). Вобщем — дело программиста.
GZ>Если объект нельзя сбросить(перечитать) в случае отката (100% протухшие данные), то нужно что-то делать. Или я чего-то не усек.
В случае отката, так же как и в случае коммита, номер транзакции увеличивается. И все данные будут невалидными. И они при необходимости — перечитаются. А что значит "нельзя сбросить(перечитать)" — я не понял, всегда можно перечитать.
GZ>правда по опыту знаю, что они постепенно приводятся к стандартизованному виду.
Хм. Читаю Фаулера — вижу одно. Смотрю 1С — другое. Смотрю "Эталон" — третье. ИМХО просто нет оптимального решения — вот и извращается кто как может .
GZ>Что касается непротиворечивости, то остался вопрос по пессимистическим транзакциям (будут или нет), масштабируемости БД и еще пожалуй, момент отката транзакций.
Про пессимистические транзакции: я же не весь фреймворк описал, это только один логический уровень. Так сказать базовый. Он больше для рассчетов (бизнес логики) подходит. Над ним уже нужно надстраивать всякие конструкторы формочек и т.д. И если для формочек нужны пессимистические транзакции — то там их и сделаем (как надстройку над этим уровнем).
Про то, что я не полностью очищаю кэш после транзакции:
— Да, после отката или завершения транзакции все данные в кэше — протухшие. Даже если они фактически не протухшие, то узнать об этом никак, только перечитав их. Я же говорил, что сессионный кэш — простой (ненавороченный). Он опирается на кэш второго уровня.
— Но, полностью кэш очищать принципиально нельзя, так как прикладная программа может держать на объекты ссылки, и такие объекты должны находиться в IdentityMap. Это нужно для чистоты концепции, так сказать.
— Более того, освобождение ресурсов, как я сказал выше, происходит только во время сборки мусора, поэтому по завершению транзакции делать ничего не нужно. Хотя, можно подумать на счет более плотной интеграции сборщика мусора с механизмом транзакций в этом смысле.
Здесь в разделе 2.3.1 описывается несколько функций кэшей. В этой терминологии сессионный кэш у меня предназначен для обеспечения Temporal и Proximal Grain, а кэш второго уровня — Morphological Grain.
Здесь в разделе 2.3.1 описывается несколько функций кэшей. В этой терминологии сессионный кэш у меня предназначен для отработки Temporal, Proximal и Morphological fine grained действий, а кэш второго уровня — Proximal и Morphological coarse grained.
Здравствуйте, GlebZ, Вы писали:
GZ>Извиняюсь забыл разъяснить про момент отката транзакций. Меня интересует вопрос: ты написал про savepoint когда объекты сбрасываются на БД. Как будет обрабатываться ошибка, если она произойдет при сбросе?
Желательно свести к минимуму такие ошибки. Например, я хочу использовать возможность отложить проверку констрейнтов до коммита (Re: реализация UnitOfWork
). Далее я ведь структуру базы тоже специальную делаю, в смысле тупых ошибок (типа, поле "аа" не найдено) при сбросе быть не должно.
Так что, получается таких ошибок не много: дед-лох, да сервер-даун.
Но, проблема такая остается. Я думаю сделать так: сделать специальный базовый класс для всех таких ексепшенов, и указать, что типа они могут возникать в любом месте транзакции, так что ловить их надо только на том логическом уровне, где идет управление транзакциями, не ниже.
Некие такие "ексепшены уровня транзакций".
Здравствуйте, stalcer, Вы писали:
S>Ну не знаю. Зачем тогда делают язык на клиенте. Это же геморрой. Но все же делают. Видимо — тормозит.
Кто делает? Какой язык?
S>Посмотрю .
S>Ну, не знаю. Даже если сделать какой-нибудь грид, который будет данные по сети качать, т.е. если его специально для этого сделать, то наверное это будет производительней, чем HTML странички. Хотя бы за счет бинарной передачи данных, и т.п.
Не, тут поинт в том, чтобы специально разрабатывать интерфейс с учетом минимизации общения между клиентом и сервером. Бинарность передачи данных сама по себе — не панацея. HTML клиент может даже порвать rich клиента за счет того, что он прокачивает только необходимые данные. Ну и плюс встроенная поддержа gzip-компрессии для передаваемого контента вместе с интеллектуальным кэшированием способна на многое. S>А хочу я, чтобы было похоже на WinForms клиент. Т.е. формочки в MDI, менюшки, панельки, ну и работа с данными — передача на клиент, чтоб не тормозила, сортировки там всякие, поиски, фильтры, кнопочки на формах и т.п.
Это все делается в рамках web-клиента без особых проблем. Многие особенности, присущие толстым клиентам, на практике малопригодны с точки зрения пользователя. Т.е. например воспроизвести всю MS VS 2005 как веб-клиента нереально. Все эти dockable tabbed interface и все такое... Но это интерфейс, ориентированный на очень специальную таргет группу. Нормальным людям, клиентам бизнес приложений, все это только вредит.
Более того, пересмотр самой модели взаимодействия приложения с пользователем в пользу "вебнутого" интерфейса помогает повысить масштабируемость приложения и улучшить user experience. Первое — потому, что там ты вынужден избегать лишних зависимостей и непроизводительной нагрузки; второе — потому, что ты вынужден тщательнее заботиться о реализации use-cases вместо хаотического запихивания всех возможностей в правую кнопку и тулбары. S>Я больше склоняюсь в тому, что это все таки возможно сделать так, чтобы приемлимо производительно работало.
Я больше склоняюсь к тому, что при проектировании клиента надо очень критически относиться к решениям, диктуемым определенной технологией разработки. Программисту очень легко забыть о том, что приложение — не упражнение по кодингу, а средство решения проблем его пользователей.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
:
И таких ситуаций можно придумать кучу. Потому как без блокировок на чтение или хотя бы таймстампы на чтение, согласованных данных не получишь.
. Но, это все равно лучше, чем read committed! Потому-что написать твой же пример правильно в read committed транзакциях тоже проблема.
.
.