| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Edit.........Post и синхронизация вызовов [D7, dBase, FoxPro]
Eraser © (2005-02-06 19:37:00)Имеется БД в виде одной таблицы dbf :)
Вызовы к БД происходят из основного потока, но может возникнуть ситуация, когда, например, пользователь редактирует информацию и в этот момент прийдёт некое внешнее сообщение, которое вызовет процедуру модификации этой БД.
Вопрос. Нужно ли защищать методы edit (append)....post например мьютексами? Т.е.
WaitForSingleObject(mxDBClient, INFINITE);
edit;
.......................
post;
sniknik (2005-02-08 17:08:00) [1]> если обращения к этой БД происходят только из основного потока, или функций, которые синхронизированы с ним?
т.е. все обрабатывается в основном. (синхронизация это тоже в основном)
что от чего зашишать? (если конечно написано так как описано ;о))
Eraser ©
не кажется что разговор какойто непредметныйпошол? (а вобщемто, он и не начинался ;)
Alexander Panov (2005-02-08 17:01:00) [2]Eraser © (08.02.05 15:43) [9]
Нужно ли обращения к DB защищать мьютексами (или кретическими секциями), если обращения к этой БД происходят только из основного потока,
Нет, не нужно.
У тебя логика приложения должна быть такой, чтобы одновременный доступ к записи не был возможен.
По существу, нужно делать полноценную эмуляцию блокировок.
Если же используется готовая БД, уже поддерживающая блокировки, то делать не нужно вообще ничего для защиты кода.
Eraser (2005-02-08 16:48:00) [3]msguns
Так и сделаю. Благодарю.
msguns (2005-02-08 16:26:00) [4]Любое обращение к потенциально опасным участкам кода, в т.ч. к тем, которые юзают "движки" и серверы БД, надо защищать, предусматривая обработку ошибок.
Eraser (2005-02-08 15:43:00) [5]Ну так есть у кого-нибудь соображения? Наверняка же сталкивались с такой ситуацией ;-)
Не хотелось бы оставлять в программе потенциальные глюки...
Ещё раз повторю вопрос. Нужно ли обращения к DB защищать мьютексами (или кретическими секциями), если обращения к этой БД происходят только из основного потока, или функций, которые синхронизированы с ним?
Eraser (2005-02-07 20:24:00) [6]msguns ©
Anatoly Podgoretsky
В вопросе я ясно сказал, что вызов происходит из ОСНОВНОГО потока. А вот sniknik хорошо подметил, что вызов происходит не из сообщения Windows, а функцией, синхронизированной с основным потоком.
Я вообще не понимаю, зачем удаление и перечитку делать в разных потоках.
Повторюсь. ВСЕ операции с БД происходят только в основном потоке, но я где-то слышал, может это не правда, что может возникнуть эффект псевдо-многопоточности, т.е. функция может быть прервана для обработки сообщения. Мне кажется тут что-то не так...
Anatoly Podgoretsky (2005-02-07 17:06:00) [7]на одно место
msguns (2005-02-07 16:56:00) [8]>sniknik © (07.02.05 15:35) [5]
Я вообще не понимаю, зачем удаление и перечитку делать в разных потоках. ИМХО, чел явно ищет себе проблемы на ровном месте.
sniknik (2005-02-07 15:35:00) [9]msguns © (07.02.05 14:09) [4]
а тут вопрос не про сервер (отдельная песня), а про то как на клиенте "рулить" одной базой(коннектом) из разных потоков. (это как сам понял, возможно ошибаюсь)
а раз так то основная проблема в том чтобы не выполнить delete (к примеру) из дополнительного потока в то время как эта самая таблица чей метод вызывается (пытается, т.к. скорее рухнет чем выполнится) усиленно узается для foolscan-а.
msguns (2005-02-07 14:09:00) [10]Потоки, процессы, "трубы" - это все программные мульки, реализующие мультиобработку кода, но никаким образом не влияющие на "сервер". Он их обрабатывает, совершенно не подозревая о каких-то там внутренних параллированиях и сообщениях. Если, конечно, не брать во внимание саму программную реализацию сервера ;) "Клиенты" же для него все одинаковы (не углубляясь в нюансы типа блокировок, приоритетов и ролей)
sniknik (2005-02-07 13:57:00) [11]да ктож его знает? как приложение написано, гарантий давать нельзя.
если у тебя вся работа с базой идет в основном потоке и из дополнительного приходит только сообщение в основной (как я понял из вопроса), то не должно. (речь не об отказе в доступе, это может и по другим причинам, а о "пересечении" когда один ресурс из двух мест одновременно затребован)
Eraser (2005-02-07 13:25:00) [12]Т.е. не может сложиться ситуация, когда пользователь жмёт "OK" и в этот же момент приходит сообщение, в результате чего или пользователю или сообщению будет отказано в доступе к БД?
sniknik (2005-02-07 02:12:00) [13]сообщение из другого потока в основном будет обрабатываться в порядке обшей очереди (если это сообщение конечно, а не прямой вызов метода)
| |
