Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
read - write - commit
|
|||
|---|---|---|---|
|
#18+
Есть файл, в котором нужно хранить структуры, для определенности пусть фиксированной длины. К нему должны иметь одновременный доступ несколько процессов на чтение - запись. Как организовать такой режим, чтобы часть процессов работала в режиме dirty read, а другая в режиме read committed? Пойму код на сях / паскале, под виндовс или под унихи. Можно использовать специфику API осей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2004, 14:07 |
|
||
|
read - write - commit
|
|||
|---|---|---|---|
|
#18+
Сделай MemoryMapped файл, опиши таблицу блокировок, которую будут расшаривать все твои процессы, когда процесс хочет писать в область памяти (MappedFile) он запрашивает у таблицы залокна ли эта запись, если нет то залокать, типа TryLockRecord(RecNum):Boolean; и пишет себе преспокойненько, при этом TryLockRecord держит копию заблокированной записи. UnLockRecord делает Flush на диск, отпускает запись, и освобождает удерживаемую копию. функция GetRecord проверяет по таблице блокировок свободна ли запись, если свободна - возвращает, если занята - возвращает ее из удерживаемой копии. Если надо наваять такой менеджер, пиши - договоримся ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2004, 17:14 |
|
||
|
read - write - commit
|
|||
|---|---|---|---|
|
#18+
мы, дятлыКак организовать такой режим, чтобы часть процессов работала в режиме dirty read, а другая в режиме read committed? Хм. У такого файла скорее всего будет некая управляющая структура - что-то типа списка записей. Тогда достаточно сделать update информации как "insert новой версии". В таблице структур хранить два указателя - на "старую" и "новую" версии. По commit-у, соответственно, старая версия переходит в свободные блоки, а указатель на новую копируется в указатель на старую. Читатель, соответственно, выбирает между тем и другим указателем для dirty/commited чтения. P.S. Но вообще-то хорошо делать это при обмене только через файл - имхо, задолбаешься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2004, 17:26 |
|
||
|
read - write - commit
|
|||
|---|---|---|---|
|
#18+
нужно просто поставить OS/400, и будет тибе щастье. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2004, 18:29 |
|
||
|
read - write - commit
|
|||
|---|---|---|---|
|
#18+
виндовс и йюнегз недарасли эщо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2004, 18:31 |
|
||
|
read - write - commit
|
|||
|---|---|---|---|
|
#18+
Shultzeпри этом TryLockRecord держит копию заблокированной записи Тут, видимо, стоит использовать режим маппинга WRITECOPY? Это имелось ввиду? Тогда не совсем понятно вот что: если процесс пишет что-то в режиме WRITECOPY, то как процессы в режиме dirty read смогут прочесть что он туда пишет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2004, 19:38 |
|
||
|
read - write - commit
|
|||
|---|---|---|---|
|
#18+
MSDN If you share the mapping between multiple processes using DuplicateHandle or OpenFileMapping and one process writes to a view, the modification is not propagated to the other process. The original file does not change. Т.е. другие процессы будут видеть в "окне" устаревшие данные. Все равно без менеджера не обойтись, иначе при компа программы непонятки начнуться, незавршенные транзакции. если записи у вас различной длины, то надо делить файл на страницы и писать соответственно кусками ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2004, 22:15 |
|
||
|
read - write - commit
|
|||
|---|---|---|---|
|
#18+
Я предлагаю человеку, скрывающемуся за ником "мы дятлы" ответить самому себе на следующие вопросы: 1) Сможешь ли ты масштабировать этот проект? Как в него добавить еще десяток таблиц (если вдруг это потребует заказчик), и организовать версионное чтение, еще и гарантировать восстановление после сбоя? 2) Насколько удобно с точки зрения ОС использовать блокировки на уровне файлов? Не лучше-ли использовать другие средства? 3) Какова гранулярность этих блокировок? 4) Насколько ЭФФЕКТИВНО windows работает с БОЛШИМ количеством блокировок? 5) Каково максимально количество блокировок которые Windows может контролировать в рамках одного открытого файла и одного процесса? 6) Как использовать индексный поиск? Сможешь ли ты организовать эффективные алгоритмы и показать что они работают лучше штатных средств? Взвесив все за и против, стоит подумать о целесообразности такого решения. Я не предлагаю использовать СУБД. Но стоит ли в тысячный раз изобретать очередной никому не нужный велосипед? Стоит ли наступать на грабли, по которым ходили разработчики пару десятков лет назад? Отвечать на эти вопросы в данном в сабже - необязательно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2004, 11:38 |
|
||
|
read - write - commit
|
|||
|---|---|---|---|
|
#18+
2 mayton Но стоит ли в тысячный раз изобретать очередной никому не нужный велосипед? Стоит ли наступать на грабли, по которым ходили разработчики пару десятков лет назад? Да, мне это интересно. Я тоже хочу побродить по этим же граблям. Сам хочу разобраться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2004, 12:51 |
|
||
|
read - write - commit
|
|||
|---|---|---|---|
|
#18+
2 Дятлы Молодец! Докладывай о результатах периодически. Буду навещать этот топик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2004, 13:04 |
|
||
|
|
start [/forum/topic.php?fid=16&msg=32791109&tid=1348072]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
162ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 255ms |
| total: | 512ms |
| 0 / 0 |
