Re[34]: Опять валидация данных
От: stalcer Россия  
Дата: 31.03.05 07:02
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Что касается фанатсва OID то я фанат GUID. В некоторой степени это обсуждалось http://gzip.rsdn.ru/Forum/Message.aspx?mid=1046863&only=1
Автор: GlebZ
Дата: 27.02.05
. Знаешь, сильно спасало.


Читал, читал.
Я выбрал следующий вид OID: OID у меня — 64'ех битное число (ну как long в C#). Оно разбито на несколько секций:
— 24 бита — TypeId
— 32 бита — HighVal
— 8 бит — LowVal

Я как бы не собираюсь работать с несколькими СУБД одновременно, и не собираюсь делать супер масштабируемое приложение. Ну, 500 юзеров — это максимум.
По этому я хотел ограничить размер OID (в битах), чтобы запихивать его в одно поле базы с типом NUMBER. Ну и чтобы память в кэше экономить тоже.
GUID для меня — слишком тяжелая штука.
http://www.lmdinnovative.com (LMD Design Pack)
Re[32]: Опять валидация данных
От: stalcer Россия  
Дата: 31.03.05 07:48
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Уровень snapshot даже оптимистической проверки не обеспечивает. Так что оптимистическая проверка должна быть обязательна.


В моем случае — эту проверку сам Oracle обеспечивает. Т.е. автоматически. И ничего для этого делать не нужно. Смотри здесь
Автор: GlebZ
Дата: 25.03.05
.
Ну и, вероятно, Oracle это несколько быстрее делает, чем если бы я сам вручную.

GZ>У диспетчера блокировок 3 функции: наложить блокировку, убрать блокировку, проверить блокировку. То есть функции одного Hashtable, где быстрота доступа O(1)(если реализация на C#). Это значительно быстрее и эффективнее чем блокировки на уровне БД. Особенно в условиях кэша.


В условиях нескольких серверов приложений с отдельными кэшами. И еще в условиях нескольких сессионных кэшей в каждом из серверов приложений. И еще в условиях (это не обсуждается, я так хочу и все!), когда кэш может выгружать ненужные в данный момент объекты, как измененные, так и просто прочитанные, неким LRU-подобным алгоритмом.

GZ>Сама задача трансформации OQL запроса в эффективный SQL достаточно интересна и сложна. Уж поверь, я этим занимался.


Да уж. Задолбался я с этим. Дык я еще только прототип сделал, над эффективностью SQL особо не думал. Так что многое еще впереди .

GZ>И подумай о том, что используя устаревшие данные просто на чтение, ты можешь базу завалить.

Напомню, что мы говорили о snapshot транзакции.

Хе. В read committed транзакции используя половину старых данных (т.к. я их уже успел прочитать, до коммита другой транзакции) и половину новых (те что после коммита другой транзакции) я базу могу завалить с гораздо более высокой вероятностью. Это я только про использование данных на чтение говорю.
Вообще постоить фреймворк, который бы не давал принципиально завалить базу — это только через по настоящему сериализованные транзакции. Причем бизнес транзакции, а не просто системные. Другими словами — на практике невозможно.

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

По этому универсального эффективного решения не существует, и придется некоторую часть ответственности переложить на плечи прикладного программиста.
http://www.lmdinnovative.com (LMD Design Pack)
Re[32]: Опять валидация данных
От: stalcer Россия  
Дата: 31.03.05 10:20
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Не плоди системы. Забудь о SQL блокировках.


Ok. Забыли.

Давай пример для дальнейших рассуждений вот это (повторяю из поста выше):

6.2: И тогда получается, что эти несколько системных транзакций — короткие (какие и должны быть SQL транзакции) и без интерактива с пользователем. При таком подходе для точной реализации задачи из пункта 5 (важны 5.1, 5.2 и 5.3) нам нужно всего лишь два механизма:
6.2.1: Оптимистические snapshot системные транзакции.
6.2.2: Механизм "блокировок уровня бизнес транзакций". См. 5.6.


Т.е. системные транзакции у нас только оптимистические. И некоторую, желаемую, долю пессимизма они получают при использовании "блокировок уровня бизнес транзакций". Эту же долю пессимизма наследует и parent бизнес транзакция.




А теперь, собственно, дальнейшие рассуждения:

Мы забыли про SQL блокировки, предположив, что можно создать свой механизм блокировок. Такой механизм должен быть достаточно производительным и глобальным по отношению к разным сессиям и серверам приложений.
Здесь можно основываться на взаимодействии через базу данных, т.е. создать специальные таблички для хранения блокировок и т.п. Но, думаю, что это будет безбожно тормозить.
Значит нужен некий центральный сервис, через который сервера приложений и общаются. Типа "сервис блокировок".

Некий абстрактный интерфейс этого сервиса, предоставляемый серверу приложений, должен быть такой:

enum LockMode
{
    Shared,
    Noshare
};

interface LockService
{
    void LockObject(long objID, LockMode lockMode, long businessTransactionId);
    void LockObjects(long[] objIDs, LockMode[] lockModes, long businessTransactionId);
    void RemoveAllTransactionLocks(long businessTransactionId);
};


Функция LockObjects чисто для оптимизации по производительности, никакой дополнительной логической нагрузки в себе не несет.
Реализовать такой интерфейс, конечно, не проблема. Пусть все работает в оперативной памяти, исходя из предположения, что блокировок будет немного.

Но поскольку сервис центральный, основная проблема будет в производительности из за сетевого взаимодействия. А будет ли это проблемой на практике или нет, зависит от характера использования этого сервиса. Поэтому проанализируем как, когда и зачем используется этот сервис.

Итак: как, когда и зачем используется сервис блокировок:

10:
Одно важное замечание: Блокировки не подчиняются уровню изоляции транзакций. То есть, если одна транзакция установила noshare блокировку, а потом вторая попытается тоже установить блокировку, то у второй не должно этого получиться.
То есть я хочу сказать, что изменения данных транзакции сразу не видят, а блокировки должны видеть сразу, т.е. получается realtime. И это плохо.

11:
В соответствии с (5.5 отсюда
Автор: stalcer
Дата: 30.03.05
) блокировки накладываются явно бизнес логикой бизнес транзакции.

12:
Но блокировки еще и накладываются неявно при любом изменении объекта в течении бизнес транзакции. То есть если я делаю:

obj.Name = "zzz";

Все! Это само по себе должно приводить к неявной устаноке noshare блокировки. Ну естественно, если она еще не была установлена для данной транзакции.
Иначе грош-цена всем этим явным блокировкам, и ни от чего они не защитят.

13:
Так как блокировние в (11) и (12) должно выполняться в realtime (см. 10), т.е. при помощи синхроного взаимодействия с сервисом блокировок, то могут быть тормоза.
Блин. Даже число — и то 13 получилось .

14:
Хотел еще вот что сказать: Использование проверки версии при оптимистическом подходе никак картину с блокировками не меняет. Все равно неявные блокировки из (12) должны остаться!

Ну вот. Если ты знаешь еще какой-нибудь интересный подход — напиши .
http://www.lmdinnovative.com (LMD Design Pack)
Re[33]: Опять валидация данных
От: GlebZ Россия  
Дата: 31.03.05 10:52
Оценка:
Здравствуйте, stalcer, Вы писали:

1. Давай сначала о U блокировках. Рассмотрим когда они нужны. Они нужны в самом начале бизнес-транзакции. Это даст большую вероятность на успех блокирования. Какими методами принудить прикладника их устанавливать, это уже другой вопрос (выделением обязательных шагов, или просто через документацию).
2. Давай посмотрим что происходит чаще: — проверка блокировки, или ее установка. По моему мнению — проверка. Поэтому предлагаю следующий вариант:
1. При начале транзакции (сессии) копируется весь список заблокированных объектов.
2. При установке новой блокировки — она распространяется на основной сервис(где проверяется нужна ли она), и затем по всем спискам блокировок.
Памяти для одной блокировки нужно не так уж много. Поэтому на копирование не должно уходить много времени.
Еще, я пока не врублюсь, а нужны ли S-блокировки при snapshot транзакции?

В интерфейсе забыл еще метод: проверка заблокирован ли объект.

п.12 неоднозначен. Есть два пути, оставить на усмотрение прикладника (он все равно получит отлуп при фиксировании транзакции), либо так.

С уважением, Gleb.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Re[35]: Опять валидация данных
От: GlebZ Россия  
Дата: 31.03.05 11:36
Оценка:
Здравствуйте, stalcer, Вы писали:

S>PS: Читай, пожалуйста, сообщения внимательней. Мы же сложные вещи обсуждаем. И они еще более сложные, потому что одно зависит от другого.

thanks, облажался
С уважением, Gleb.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Re[35]: Опять валидация данных
От: GlebZ Россия  
Дата: 31.03.05 11:36
Оценка:
Здравствуйте, stalcer, Вы писали:

3 случая из практики.
1. Впихнул информацию о TypeID в primary key. Ну и пользовался им как информацией о типе. После некоторого момента — получил неприятность в том, что произошла эволюция типов. Пришлось отказаться от TypeID как информационной части объекта.
2. После того, как была продана система с филиалами, оказалось что система идентификации на БД не позволяла просто так это делать. Как обычно продают раньше чем сделают. Пришлось делать сложный механизм маршрутизации ключей (в другом случае обошлись введением дополнительного поля GUID).
3. Клиентам была поставлена тестовая база. После того, как они туда вбили кучу полезной информации (тестировали они так), они попросили перенести информацию на боевую. После выставленного счета, они согласились снова вбить информацию.

Просто, информация для размышлений об уникальности данных.

С уважением, Gleb.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Re[34]: Опять валидация данных
От: stalcer Россия  
Дата: 31.03.05 11:56
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>2. Давай посмотрим что происходит чаще: — проверка блокировки, или ее установка.


Где вообще может понадобиться проверка блокировки. Я даже и не думал ее вообще делать.
ИМХО неявная проверка обязательно нужна в момент установления блокировки, то есть внутри сервиса блокировок.

GZ>Еще, я пока не врублюсь, а нужны ли S-блокировки при snapshot транзакции?


Мы говорим о блокировках на уровне бизнес транзакций! Бизнес транзакция у нас — не snapshot. Это системная транзакция — snapshot. Т.е. каждый из шагов бизнес транзакций — snapshot, в целом она — нет.
А S-блокировки — они ИМХО нужны. И именно для бизнес транзакций.

GZ>В интерфейсе забыл еще метод: проверка заблокирован ли объект.


См. выше.

GZ>п.12 неоднозначен. Есть два пути, оставить на усмотрение прикладника (он все равно получит отлуп при фиксировании транзакции), либо так.


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

Первая:
obj.Lock(LockMode.Shared); // Заблокировали, специально, чтобы никто в течении 
                           // этой бизнес транзакции не изменил этот объект.
                           // Причем сами мы менять его не собираемся.
// Долго-долго работаем с obj.
commit;

Вторая:
obj.Name = "xxx";
commit;


Если вторая не блокирует объект неявно при изменении, то спрашивается навига первая блокировала. И если эти две транзакции писали разные прикладники, то первый будет очень сильно удивлен поведением системы. Потому-что с его точки зрения он объект заблокировал. И этот объект не должен был измениться на протяжении всей бизнес транзакции (т.е. нескльких системных snapshot транзакций).

Аналогично, при любом update'е СУБД тоже ставит неявную U-блокировку. Но мы же забыли про SQL блокировки, тем более что в Oracle нет S-блокировок. Так что надо самим теперь это делать.
http://www.lmdinnovative.com (LMD Design Pack)
Re[36]: Опять валидация данных
От: stalcer Россия  
Дата: 31.03.05 12:06
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>thanks, облажался


Ну дык вот, что я изначально хотел сказать-то этим:

Так как язык запросов является неотемлимой частью системы, и так как теперь ясно, что необходимо сбрасывать накопившиеся изменения в базу перед выполнением запроса, то это значит, что кэш будет сбразывать изменения в ходе транзакции.
Это в свою очередь означает, что на протяжении всей системной транзакции (не бизнес транзакции) должна быть соответствующая SQL транзакция, тем более что через нее мы не только сбрасываем изменения, но и читаем данные.
А так как системная транзакция должна быть короткой, а бизнес транзакция вполне может быть длинной, то их придется разделить!

Вот и получаем, что одна бизнес транзакция состоит из нескольких системных. Несмотря на недостатки такого подхода — другого выхода я не вижу.
http://www.lmdinnovative.com (LMD Design Pack)
Re[36]: Опять валидация данных
От: stalcer Россия  
Дата: 31.03.05 12:13
Оценка:
Здравствуйте, GlebZ, Вы писали:

Да-да-да. Эволюция структуры — это отдельный разговор.

Давай-ка посмотрим, в какой степени сама СУБД поддерживает эволюцию структуры реляционной базы. Сразу скажу, ИМХО в недостаточной.
Но, такую же примерно степень я могу устроить для бизнес объектов.

Так же как и запись в БД не может быть перенесена в другую таблицу, а может быть лишь скопирована, т.е. это будет пусть и такая-же, но не та-же запись, также и у меня можно копировать объекты . Ну, и где разница?
http://www.lmdinnovative.com (LMD Design Pack)
Re[35]: Опять валидация данных
От: GlebZ Россия  
Дата: 31.03.05 12:24
Оценка:
Здравствуйте, stalcer, Вы писали:

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


GZ>>2. Давай посмотрим что происходит чаще: — проверка блокировки, или ее установка.


S>Где вообще может понадобиться проверка блокировки. Я даже и не думал ее вообще делать.

S>ИМХО неявная проверка обязательно нужна в момент установления блокировки, то есть внутри сервиса блокировок.
Maybe. Ты выбрал путь.

S>Мы говорим о блокировках на уровне бизнес транзакций! Бизнес транзакция у нас — не snapshot. Это системная транзакция — snapshot. Т.е. каждый из шагов бизнес транзакций — snapshot, в целом она — нет.

S>А S-блокировки — они ИМХО нужны. И именно для бизнес транзакций.
Именно. Попробуй опиши что должна делать S-блокировка при условии что у нас нет X-блокировок.

GZ>>п.12 неоднозначен. Есть два пути, оставить на усмотрение прикладника (он все равно получит отлуп при фиксировании транзакции), либо так.


S>Аналогично, при любом update'е СУБД тоже ставит неявную U-блокировку. Но мы же забыли про SQL блокировки, тем более что в Oracle нет S-блокировок. Так что надо самим теперь это делать.

Ты выбрал путь.
Считаю достоинством второго пути — принуждение прикладника явно блокировать объекты перед изменением. Может быть и с использованием дополнительных средств.
Недостаток в данном случае которые я вижу:
— то что прикладник никогда не знает откуда он может получить отлуп. Он может произвести большое кол-во действий, и при этом получить откат в неизвестном месте.
— то что прикладник явно блокируя объекты, может заблокировать их в начале бизнес-транзакции. Этим он обеспечит большую вероятность успеха транзакции. А неуспех при пессимистической транзакции (а она предназначена именно для максимального успеха транзакции) не очень приятно.

С уважением, Gleb.

PS:Только что получил очередной дедлок в Janus'e. Прикольно.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Re[33]: Опять валидация данных
От: Sinclair Россия https://github.com/evilguest/
Дата: 31.03.05 12:37
Оценка: 55 (2)
Здравствуйте, stalcer, Вы писали:
S>Вот пример, который я приводил выше:
Совершенно верный подход к проблеме. Именно из-за этого я не очень люблю O/R Mapping — системы.
В идеальной ООСУБД такой проблемы возникнуть не может, т.к. сам механизм обеспечивает все что надо. Движок запросов в курсе про кэш, и использует его как обычно — чтобы минимизировать трафик с диском. При выполнении запроса сначала строится план, потом он исполняется. Фактически, все предикаты вычисляются именно в кэше, в который по мере необходимости поднимаются объекты. Именно так работают RDBMS.

Если мы хотим получить в рамках апп-сервера функциональность, аналогичную ООСУБД, то придется следовать той же стратегии. Есть два с половиной варианта:
1. Использовать полностью свой движок запросов. РСУБД при этом отвечает исключительно за хранение данных, несколько упрощая манипуляции по сравнению с "голой" файловой системой.
При этом можно даже получить не слишком плохую производительность, но ценой написания весьма и весьма дорогостоящего оптимизатора запросов — иначе в память будет подниматься слишком много лишних объектов.
2. По максимуму использовать движок SQL запросов. Тогда надо дать ему достаточное количество данных, т.е. все модификации должны прозрачно скидываться в БД. Кэш объектов в таком разе может быть полезен только для навигационных запросов, т.к. ассоциативные запросы его не используют (ну, точнее все равно будет некоторая экономия на инстанцировании объектов).
2,5. Смешанный подход. Запросы выполняются по двум хранилищам — СУБД и кэшу. Результаты соответствующим образом мерджатся. В принципе, при аккуратной реализации можно сочетать лучшие черты обоих подходов. Потому как оптимизацией "массовой" части запроса будет заниматься движок СУБД, а анализ измененных объектов в кэше можно сделать и прямым перебором. Он будет не слишком плох, т.к. во-первых этих измененных объектов в каждый момент не так много, а во-вторых они все уже в памяти (не секрет, что основная потеря производительности в БД уходит на дисковый обмен).


Еще я хотел бы отметить, что в данном контексте мы неявно перешли от OQL, который позволяет очень-очень много чего, к чему-то типа OCL. Потому что все обсуждаемые запросы сводятся к получению списка объектов. OQL позволяет возвращать самые дикие структуры, которые не соответствуют никакому исходному типу данных. Попытка реализовать полноценный OQL поверх РСУБД, что с кэшированием, что без — это практически самоубийство.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[36]: Опять валидация данных
От: stalcer Россия  
Дата: 31.03.05 12:54
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Именно. Попробуй опиши что должна делать S-блокировка при условии что у нас нет X-блокировок.


Так. Стоп-стоп. Чего-то я перепутался. Я говорю о двух типах блокировок: shared и noshare. Насколько я понял, это тоже самое, что ты называешь S-блокировкой и U-блокировкой. X-блокировка, это на сколько я понял — блокировка на чтение. Если да, то таких у нас нет.

Под shared я понимаю такую блокировку: При блокировнии объекта shared блокировкой:
— если объект не был заблокирован — блокировка возможна.
— если объект был заблокирован shared блокировкой — блокировка возможна.
— если объект был заблокирован noshare блокировкой — блокировка невозможна.

Под noshare я понимаю такую блокировку: При блокировнии объекта noshare блокировкой:
— если объект не был заблокирован — блокировка возможна.
— если объект был заблокирован shared блокировкой — блокировка невозможна.
— если объект был заблокирован noshare блокировкой — блокировка невозможна.

Здесь
Автор: stalcer
Дата: 30.03.05
в пункте (5.4) я описал, что объект, представляющий сам товар я блокирую shared блокировкой. Это потому, что я хочу, чтобы на протяжении всей бизнес транзакции этот объект не менялся. Но сам я его тоже менять не хочу, и поэтому позволяю остальным аналогичным транзакциям тоже блокировать его shared блокировкой.

Т.е. на трех кассах одновременно продают "ириску". Каждая блокирует объект "товар-ириска", т.е. они блокируют его одновременно, по этому и блокировка называется shared. Но зато пока они не закончат свои транзакции, тетка на складе не сможет удалить или изменить этот объект.

Т.е. shared блокировка не запрещает никому читать данные, но запрещает их изменять. Но от noshare отличается тем, что не запрещает также, другим устанавливать shared блокировку, т.е. не запрещает другим запрещать изменение объекта .

S>>Аналогично, при любом update'е СУБД тоже ставит неявную U-блокировку. Но мы же забыли про SQL блокировки, тем более что в Oracle нет S-блокировок. Так что надо самим теперь это делать.

GZ>Ты выбрал путь.

Путь-то я выбрал, т.е. предложил. И хочу посоветоваться не будет ли этот путь тормозить. А еще лучше, как сделать так, чтобы этот путь не тормозил. Как сделать сервис блокировок?

GZ>PS:Только что получил очередной дедлок в Janus'e. Прикольно.


Ни разу не видел .
http://www.lmdinnovative.com (LMD Design Pack)
Re[34]: Опять валидация данных
От: GlebZ Россия  
Дата: 31.03.05 13:14
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Если мы хотим получить в рамках апп-сервера функциональность, аналогичную ООСУБД, то придется следовать той же стратегии. Есть два с половиной варианта:

S>1. Использовать полностью свой движок запросов. РСУБД при этом отвечает исключительно за хранение данных, несколько упрощая манипуляции по сравнению с "голой" файловой системой.
S>При этом можно даже получить не слишком плохую производительность, но ценой написания весьма и весьма дорогостоящего оптимизатора запросов — иначе в память будет подниматься слишком много лишних объектов.
Не слишком плохую производительность? Уменьшая селективность запроса? Не очень верю.
S>2. По максимуму использовать движок SQL запросов. Тогда надо дать ему достаточное количество данных, т.е. все модификации должны прозрачно скидываться в БД. Кэш объектов в таком разе может быть полезен только для навигационных запросов, т.к. ассоциативные запросы его не используют (ну, точнее все равно будет некоторая экономия на инстанцировании объектов).
+1
S>2,5. Смешанный подход. Запросы выполняются по двум хранилищам — СУБД и кэшу. Результаты соответствующим образом мерджатся. В принципе, при аккуратной реализации можно сочетать лучшие черты обоих подходов. Потому как оптимизацией "массовой" части запроса будет заниматься движок СУБД, а анализ измененных объектов в кэше можно сделать и прямым перебором. Он будет не слишком плох, т.к. во-первых этих измененных объектов в каждый момент не так много, а во-вторых они все уже в памяти (не секрет, что основная потеря производительности в БД уходит на дисковый обмен).
+21


S>Еще я хотел бы отметить, что в данном контексте мы неявно перешли от OQL, который позволяет очень-очень много чего, к чему-то типа OCL. Потому что все обсуждаемые запросы сводятся к получению списка объектов. OQL позволяет возвращать самые дикие структуры, которые не соответствуют никакому исходному типу данных. Попытка реализовать полноценный OQL поверх РСУБД, что с кэшированием, что без — это практически самоубийство.

OQL — это уже имя нарицательное. Под ним, можно иметь ввиду уже любой язык который может адресовать объектные структуры. Будет ли это объектом, или нет — не важно. Но намек понравился, правильный.

С уважением, Gleb.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Re[34]: Опять валидация данных
От: stalcer Россия  
Дата: 31.03.05 13:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>1. Использовать полностью свой движок запросов. РСУБД при этом отвечает исключительно за хранение данных, несколько упрощая манипуляции по сравнению с "голой" файловой системой.


Возможно, но не подходит. Слишком сложно в реализации, и не практично. Все таки именно в СУБД должны выполняться запросы (хатя бы их часть, как в твоем пункте 2,5), для того чтобы сервер приложений не обрабатывал громадные массивы данных.

S>При этом можно даже получить не слишком плохую производительность, но ценой написания весьма и весьма дорогостоящего оптимизатора запросов — иначе в память будет подниматься слишком много лишних объектов.


Спорить не буду. Я для этого еще слишком маленький .

S>2. По максимуму использовать движок SQL запросов. Тогда надо дать ему достаточное количество данных, т.е. все модификации должны прозрачно скидываться в БД. Кэш объектов в таком разе может быть полезен только для навигационных запросов, т.к. ассоциативные запросы его не используют (ну, точнее все равно будет некоторая экономия на инстанцировании объектов).


Это тот вариант который я выбрал.

S>2,5. Смешанный подход. Запросы выполняются по двум хранилищам — СУБД и кэшу. Результаты соответствующим образом мерджатся. В принципе, при аккуратной реализации можно сочетать лучшие черты обоих подходов. Потому как оптимизацией "массовой" части запроса будет заниматься движок СУБД, а анализ измененных объектов в кэше можно сделать и прямым перебором. Он будет не слишком плох, т.к. во-первых этих измененных объектов в каждый момент не так много, а во-вторых они все уже в памяти (не секрет, что основная потеря производительности в БД уходит на дисковый обмен).


Это тот вариант в который может быть когда-нибудь перерастет мой текущий. Я пока тоже не готов обсуждать этот вариант, так как знаний недостаточно, но думаю, здесь одной из самых острых проблем будет так называемая cache-compliteness-problem.
И еще не известно, насколько после решения этой проблемы производительность будет лучше чем в варианте (2).
И также неизвестно, вообще, в принципе возможно ли выполнение любого запроса без сброса кэша в базу. Т.е. всегда ли возможно обойтись одной лишь коррекцией результатов запроса, с учетом кэшированных данных, пусть и очень сложной. Вероятнее всего в некоторых случаях дешевле будет все-таки сбросить кэш.

S>Еще я хотел бы отметить, что в данном контексте мы неявно перешли от OQL, который позволяет очень-очень много чего, к чему-то типа OCL. Потому что все обсуждаемые запросы сводятся к получению списка объектов. OQL позволяет возвращать самые дикие структуры, которые не соответствуют никакому исходному типу данных. Попытка реализовать полноценный OQL поверх РСУБД, что с кэшированием, что без — это практически самоубийство.


Ты, наверное когда говоришь "OQL", имеешь ввиду какой-нибудь стандарт. Я же просто имею ввиду некоторый язык запросов, где прикладнику не нужно писать имена таблиц, а можно писать имена классов объектов, ну и другие полезные фишечки. И проверка синтаксиса у учетом метаданных.

Я вообще думаю, что не стоит делать сложный язык запросов. Я вижу роль языка запросов с общей картине следующую: он больше нужен, чтобы минимизировать объем данных, прокачиваемый через сервер приложений. То есть с его помощью делается первичная выборка, которая затем может дополнительно фильтроваться просто циклом на сервере приложений. Т.е. прикладной программой.
http://www.lmdinnovative.com (LMD Design Pack)
Re[35]: Опять валидация данных
От: stalcer Россия  
Дата: 31.03.05 13:23
Оценка:
Здравствуйте, GlebZ, Вы писали:

Да, конечно. Пункт (2,5) — красивая мечта!
http://www.lmdinnovative.com (LMD Design Pack)
Re[37]: Опять валидация данных
От: GlebZ Россия  
Дата: 31.03.05 13:58
Оценка:
Здравствуйте, stalcer, Вы писали:

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


GZ>>Именно. Попробуй опиши что должна делать S-блокировка при условии что у нас нет X-блокировок.


S>Так. Стоп-стоп. Чего-то я перепутался. Я говорю о двух типах блокировок: shared и noshare. Насколько я понял, это тоже самое, что ты называешь S-блокировкой и U-блокировкой. X-блокировка, это на сколько я понял — блокировка на чтение. Если да, то таких у нас нет.

Да.

S>Под shared я понимаю такую блокировку: При блокировнии объекта shared блокировкой:

S>- если объект не был заблокирован — блокировка возможна.
S>- если объект был заблокирован shared блокировкой — блокировка возможна.
Много блокировок на один объект?
S>- если объект был заблокирован noshare блокировкой — блокировка невозможна.

S>Под noshare я понимаю такую блокировку: При блокировнии объекта noshare блокировкой:

S>- если объект не был заблокирован — блокировка возможна.
S>- если объект был заблокирован shared блокировкой — блокировка невозможна.
S>- если объект был заблокирован noshare блокировкой — блокировка невозможна.

S>Здесь
Автор: stalcer
Дата: 30.03.05
в пункте (5.4) я описал, что объект, представляющий сам товар я блокирую shared блокировкой. Это потому, что я хочу, чтобы на протяжении всей бизнес транзакции этот объект не менялся. Но сам я его тоже менять не хочу, и поэтому позволяю остальным аналогичным транзакциям тоже блокировать его shared блокировкой.

U-блокировка делает то же самое.
Основное свойство S-блокировки, не допустить X-блокировку или как ты сказал блокировку на чтение. В данном случае я не вижу в ней смысл.
S>>>Аналогично, при любом update'е СУБД тоже ставит неявную U-блокировку. Но мы же забыли про SQL блокировки, тем более что в Oracle нет S-блокировок. Так что надо самим теперь это делать.
GZ>>Ты выбрал путь.

S>Путь-то я выбрал, т.е. предложил. И хочу посоветоваться не будет ли этот путь тормозить. А еще лучше, как сделать так, чтобы этот путь не тормозил. Как сделать сервис блокировок?

Видоизмени то что я предложил. По моему — шняга с копированием списков должна убыстрить. Но ессно IMHO.

GZ>>PS:Только что получил очередной дедлок в Janus'e. Прикольно.


S>Ни разу не видел .

Не знаю в чем дело (я недавно им пользуюсь) но чего-то оно происходит достаточно часто.

С уважением, Gleb.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Re[6]: Опять валидация данных
От: Сомов Александр Россия  
Дата: 31.03.05 14:06
Оценка:
S>Таким образом получается, что для работы с формами лучше иметь бизнес объекты с:
S>

S>А для программной работы лучше иметь визнес объекты, написанные по всем правилам ООП:

S>
S>Получается противочечие .


На самом деле это решается паттерном builder. Т.е. есть объект builder, который используется для построения бизнес-объекта. Конструктор пустой, и все свойста для заполнения присутствуют. Как только программист решает, что все данные собраны, он делает newBusinessObject = builder.Create(). И вот Create либо возвращает объект в согласованном состоянии, либо выкидывает исключение. (Кстати, самый простой пример — это StringBuilder (из .NET), правда он как раз всегда может создать строку в согласованном состоянии, но зато мы не увидим строку до того, как всё её содержимое будет собрано).
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
Re[7]: Опять валидация данных
От: stalcer Россия  
Дата: 01.04.05 06:08
Оценка:
Здравствуйте, Сомов Александр, Вы писали:

СА>На самом деле это решается паттерном builder. Т.е. есть объект builder, который используется для построения бизнес-объекта. Конструктор пустой, и все свойста для заполнения присутствуют. Как только программист решает, что все данные собраны, он делает newBusinessObject = builder.Create(). И вот Create либо возвращает объект в согласованном состоянии, либо выкидывает исключение. (Кстати, самый простой пример — это StringBuilder (из .NET), правда он как раз всегда может создать строку в согласованном состоянии, но зато мы не увидим строку до того, как всё её содержимое будет собрано).


Вы это программистам-прикладникам расскажите . Который просто хотят добавить в систему, например, "справочник городов". И хотят сделать это за 2 минуты. И преимущественно кликаньем мышкой по мастерам. И чтобы форма сама построилась. И. т.д. и .т.п.

Они за вами после этого неделю с топором носиться будут.
И ведь поймают в конце-концов. Потому что их больше.

Если серьезно, то мне в этом отношении нравиться Delphi. Вот с какой точки зрения: Delphi не заставляет среднего пользователя писать объектно-ориентированные вещи. Пользователи преимущественно используют уже готовые (т.е. VCL).
А как известно, писать библиотеки в ОО стиле гораздо-гораздо-гораздо сложнее, чем использовать их.

Поэтому в фреймворке я хочу, чтобы всякие справочники (и бизнес объекты для них) создавались мастерами, т.е. визуальными средствами, например, как в 1С.
А использовать их в бизнес логике, естественно программно.
http://www.lmdinnovative.com (LMD Design Pack)
Re[38]: Опять валидация данных
От: stalcer Россия  
Дата: 01.04.05 06:30
Оценка:
Здравствуйте, GlebZ, Вы писали:

S>>Под shared я понимаю такую блокировку: При блокировнии объекта shared блокировкой:

S>>- если объект не был заблокирован — блокировка возможна.
S>>- если объект был заблокирован shared блокировкой — блокировка возможна.
GZ>Много блокировок на один объект?

В этом весь и смысл. Ну например, могут же две проги держать открытым один и тот же файл, но только в read режиме. Вот каждая из них и блокирует этот файл shared блокировкой.
А зачем они (проги) ставят блокировки — чтобы не разрешить третьей проге открыть файл в режиме write (так как открывая файл в режиме write третья прога должна наложить noshare блокировку, и у нее это не получится).

S>>Здесь
Автор: stalcer
Дата: 30.03.05
в пункте (5.4) я описал, что объект, представляющий сам товар я блокирую shared блокировкой. Это потому, что я хочу, чтобы на протяжении всей бизнес транзакции этот объект не менялся. Но сам я его тоже менять не хочу, и поэтому позволяю остальным аналогичным транзакциям тоже блокировать его shared блокировкой.

GZ>U-блокировка делает то же самое.

Что "то же самое"? Разве можно наложить много U-блокировок на один объект. Я же написал "...и поэтому позволяю остальным аналогичным транзакциям тоже блокировать его..."

S>>Путь-то я выбрал, т.е. предложил. И хочу посоветоваться не будет ли этот путь тормозить. А еще лучше, как сделать так, чтобы этот путь не тормозил. Как сделать сервис блокировок?

GZ>Видоизмени то что я предложил. По моему — шняга с копированием списков должна убыстрить. Но ессно IMHO.

Ладно, над некоторым кэшированием блокировок на сервере приложений надо подумать.

У меня еще вот какой вопрос: сервис блокировок — центральный сервис. И он должен быть живучее отдельно взятого сервера приложений.
И главный вопрос, как сделать так чтобы он мог засекать падения серверов приложений, ну и обрабатывать их. А то сессия заблокирует и накроется. И все остальные будут висеть.

Да, еще дед-локи надо определять. Не так все тривиально получается.
http://www.lmdinnovative.com (LMD Design Pack)
Re[39]: Опять валидация данных
От: GlebZ Россия  
Дата: 01.04.05 10:04
Оценка:
Здравствуйте, stalcer, Вы писали:

S>Что "то же самое"? Разве можно наложить много U-блокировок на один объект. Я же написал "...и поэтому позволяю остальным аналогичным транзакциям тоже блокировать его..."

OK. Структура сервиса усложняется.

S>>>Путь-то я выбрал, т.е. предложил. И хочу посоветоваться не будет ли этот путь тормозить. А еще лучше, как сделать так, чтобы этот путь не тормозил. Как сделать сервис блокировок?

GZ>>Видоизмени то что я предложил. По моему — шняга с копированием списков должна убыстрить. Но ессно IMHO.

S>Ладно, над некоторым кэшированием блокировок на сервере приложений надо подумать.


S>У меня еще вот какой вопрос: сервис блокировок — центральный сервис. И он должен быть живучее отдельно взятого сервера приложений.

S>И главный вопрос, как сделать так чтобы он мог засекать падения серверов приложений, ну и обрабатывать их.
Для серверов приложений это не проблема. Просто нужен сервис который будет опрашивать сервера приложений через какой-то промежуток времени. В случае недоступности (а тут возможна некоторая усложненная процедура определения недоступности) то закрытие блокировок. Как только сервер-приложений вновь стал видимым, то он должен переслать свои блокировки еще раз. В случае невозможности блокирования — заинтересованные транзакции должны быть отбиты.
S>А то сессия заблокирует и накроется. И все остальные будут висеть.
Значительно хуже если надо делать зависимость от удаленных клиентов. В этом случае можно говорить только об одностороннем канале связи. То есть, клиент должен удерживать свою сессию.
S>Да, еще дед-локи надо определять. Не так все тривиально получается.
А тут все просто.
Вариант 1.
Тебе на фиг не сдались ожидание разблокирования. Обычно в серверах приложений так и делают.
Вариант 2.
Ожидание по некоторому небольшому timeout. В ожидании того, что конкурирующая транзакция достаточно коротка.
Вариант 3.
Наиболее сложный. Построение ациклического графа блокировок. Но спасибо Кодту, за готовую реализацию
Re[7]: Дедлоки!
Автор: Кодт
Дата: 21.10.04

Или ты имел ввиду дедлоки БД?

С уважением, Gleb.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.