---|Ветка была без названия|---

← →
altarasjuk (2003-03-06 23:21) [80]

У меня была подобная проблема правда с Accessom и через ADO, но в потоках суть может сводиться к следующему:
попробуй mutex мне помогло (API CreateMutext,WaiteForSingleObject) глянешь в хелп по ним, они довольно простые. может поможет. Тока mutex нужно создавать один раз для всей проги и ОБЯЗАТЕЛЬНО его удалять.

← →
zacho (2003-03-06 23:26) [81]

> Хочу, чтобы Вы все-таки поняли, что для меня не составляет
> никакого труда перевести все на MS Jet, MS SQL, MySQL, InterBase
> или что-то подобное

Без обид :-), я не знаю, есть ли у тебя опыт такого рода "перевода".
У меня - есть. Поэтому хочу предостеречь: перевести систему с одной СУБД на другую (а тем более с файл-серверной БД на полноценную РСУБД) не намного проще, чем разработать ее с нуля. Конечно, если не ставить целью получить тормозное глюкало :) Или если система (по крайней мере сама БД) весьма простая.

← →
MsGuns (2003-03-06 23:37) [82]

>ki11er

Было бы, ИМХО, целесообразным хорошенько тебе подумать и как можно конкретнее и внятно сформулировать суть проблемы, не поленившись описать текущую ситуацию и то, что в конце-концов надо получить. Не вдаваясь ни в какие сессии, потоки и прочие детали реализации.
Все это написать в сабже к новой ветке. А эту пора положить в архив. Больно здоровая, а толку - чуть.

С уважением.

← →
ki11er (2003-03-07 12:20) [83]

2 altarasjuk:
не, так не пойдет, я уже писал выше...

2 zacho:
"БД" очень простая - одна таблица ;-))) Опять же об этом писалось выше не один раз. На SQL пробовал - за исключением пары мелких проблем все нормально. Но не хотелось бы из пушки стрелять по комарам ;-)))

2 MsGuns:
Ok. Открою новую и еще раз напишу ;-)))

← →
Anatoly Podgoretsky (2003-03-07 14:47) [84]

Незачем спам разводить, хватит и одной ветки

← →
ki11er (2003-03-07 16:39) [85]

Новую ветку запретил модератор. Будем мучаться здесь :(

Итак, раз здесь не нашлось любителей решать задачу просто потому, что она не решена без привязки к объектам окружающей действительности, попробую еще раз описать реальную задачу.

1. Есть написанное на Delphi многофункциональное приложение.
2. При работе в одном из режимов возникают проблемы с таблицей (чаще всего с индексами).
3. Работа с таблицей построена через BDE, сама таблица - Paradox.
4. Таблица имеет порядка 20 полей (типы - лонг, стамп, строка, логический). Автоинкремента нет. Один первичный индекс (лонг), 2 вторичных - 1. лонг+лонг; 2. лонг.
5. "Глобально" переделывать приложение (менять БД, менять структуру самого приложения, ...) у меня пока нет никакого желания, а точнее говоря, я не вижу предпосылок для этого, так как согласно документации, все должно работать в существующем варианте с минимальными переделками.
6. Для того, чтобы с горяча не править само приложение было принято решение написать тест, на нем все отработать и потом перенести в целевую программу.
7. Теперь о том, что должна программа в этом режиме делать. С многоканального оборудования асинхронно поступают данные, которые должны заноситься в таблицу достаточно быстро, иначе могут потеряться (при выполнении только этой задачи - запас по времени достаточно большой). Одновременно с этим должна производиться обработка полученной информации. Эта обработка включает в себя относительно длинный SQL-запрос и некоторую модификацию таблицы. Одновременно с этим пользователь может захотеть просмотреть данные, причем имеет возможность настроить достаточно "извращенную" фильтрацию, чтобы соответствующий SQL-запрос тоже выполнялся достаточно долго. При желании, пользователь может модифицировать некоторые поля таблицы (правда это делается достаточно редко). На самом деле все несколько сложнее, но пусть задача будет сформулирована так.
8. Надеюсь, понятно, что основная задача - записать данные, а остальная обработка может идти относительно медленно.

Способы решения:
1. Заставить работать многопоточный вариант.
2. Разграничить доступ потокам через синхронизацию, но появляется риск потерять данные, что не есть хорошо, а очень даже плохо.
3. Буферизовать обращения к таблице с риском войти в "клинч", когда система по каким-то причинам не станет справляться с нагрузкой. А это есть уже совсем нехорошо.

...

← →
Mike Kouzmine (2003-03-07 16:47) [86]

Сколько раз инициализируется БДЕ в твоей программе?
Один раз или несколько?
Если один раз, то сколько бы потоков не выполнялось, БДЕ будет писать данные последовательно, то есть сначала обрабаотает один запрос, затем другой... Исходя из этого, что многопоточный доступ, что однопоточный, по барабану. И нет смысла все это городить.
Если бы я писал эту программу, то сделал бы объект, который бы собирал асинхронно данные, а затем в какой-то момент писал бы это все в базу.

← →
sniknik (2003-03-07 17:00) [87]

(писал уже в грохнутой ветке)
можно организовать очередь из сообщений, в принципе ничего терятся не должно.

многопоточный вариант записи в базу, только затормозит процесс, что скорее приведет к потере данных. (оптимум 2 потока 1 на запись и 1 на чтение, было бы ADO то 2 асинхронно работающих компонента)
время выполнения 2х потоков = время одного + время другого + время на переключение, вообще потоки имеют смысл если система простаивает (в режиме ожидания) а несколько со стопроцентной загрузкой не будут быстрее одного.

(надеюсь понятно изложил, its мое мнение, переубеждению не подлежит :-)))

Mike Kouzmine (07.03.03 16:47)
> что многопоточный доступ, что однопоточный, по барабану
я бы даже сказал больше (и сказал :)), что наоборот тормознее будет, с такими потоками.

← →
Mike Kouzmine (2003-03-07 17:16) [88]

sniknik © > Я читал и полностью согласен, просто хотелось с новыми силами еще раз про это...

← →
ki11er (2003-03-07 17:41) [89]

2 Mike Kouzmine & sniknik:
Еще раз смотрим вот сюда:
http://www.elance.ru/ki11er/Paradox.jpg

про стопроцентную нагрузку никто не говорит, это вообще не реализуемо...

← →
Mike Kouzmine (2003-03-07 17:51) [90]

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

← →
ki11er (2003-03-07 17:58) [91]

> Сколько раз инициализируется БДЕ в твоей программе?
> Один раз или несколько?

Что имеется в виду?

← →
Mike Kouzmine (2003-03-07 18:07) [92]

То что спрашивается, то и имеется. Сколько раз происходит инициализация BDE?

← →
ki11er (2003-03-07 18:12) [93]

> Разговор идет о том, что многопоточный доступ к файл-серверным
> базам в том виде в котором ты хочешь работать нелогичен
> по своей сути, и по ограничения движка. И дело не в том,
> что есть у тебя ошибка в коде или нет ее, сам вопрос, скажем
> так, не имеет ответа за отсутствием оного.

И еще раз смотрим :-(
http://www.elance.ru/ki11er/Paradox.jpg

← →
ki11er (2003-03-07 18:24) [94]

> То что спрашивается, то и имеется. Сколько раз происходит
> инициализация BDE?

Я не знаю, что это такое, соответственно ни разу.

← →
Mike Kouzmine (2003-03-07 18:24) [95]

Я не только посмотрел, но и рапечатал и повесил на стенку.
Но суть-то от этого не меняется. Вот если бы ты создал новый процесс и для него инициировал бы бде, то, теоретически, можно было бы производить однотипную операцию "одновременно", заметь ковычки.

← →
ki11er (2003-03-07 18:30) [96]

← →
Mike Kouzmine (2003-03-07 18:41) [97]

Сделай программу, которая будет читать или писать из базы, и запусти ее н раз. Вылетит та же ошибка. Ни на какие мысли не наводит это?

← →
ki11er (2003-03-07 18:48) [98]

> Я не только посмотрел, но и рапечатал и повесил на стенку.
> Но суть-то от этого не меняется.

Т.е. "не верь глазам своим"?

> "одновременно", заметь ковычки

Заметил, это не обсуждается...
В чем разница с точки зрения работы с базой (через BDE) между 2мя процессами и 2мя потоками (за исключением, конечно того, что доп. процесс добавит доп. проблем)?

← →
Mike Kouzmine (2003-03-07 18:54) [99]

Ты знаешь, надо почитать, в принципе код должен работать, ну кроме
procedure CTestThread.AfterPost(DataSet: TDataSet);
begin
FTable.FlushBuffers;
end;
По идее он должен выкинуть эксепшен что датасет не в Insert or Edit mode

← →
Mike Kouzmine (2003-03-07 18:55) [100]

Но это на первый взгляд.

← →
Mike Kouzmine (2003-03-07 19:00) [101]

Попробуй, как тебе советовали, создавать и TDatabase для каждой таблицы, на нее сессию, а на таблицу этот TDatabase

← →
Mike Kouzmine (2003-03-07 19:03) [102]

Потом actcount - это глобальная переменная? В нее пишут все потоки?
Как происходит взаимодействие с визуальными компанентами твоих потоков?

← →
ki11er (2003-03-07 19:51) [103]

> Сделай программу, которая будет читать или писать из базы,
> и запусти ее н раз. Вылетит та же ошибка. Ни на какие мысли
> не наводит это?

А на какие мысли это должно наводить? К тому же сделал уже давно - достаточно почитать то, что было написано выше...

> procedure CTestThread.AfterPost(DataSet: TDataSet);
> begin
> FTable.FlushBuffers;
> end;
> По идее он должен выкинуть эксепшен что датасет не в Insert
> or Edit mode

;-) Практически во всех мануалах советуют это делать (либо так, как написано, либо через DbiSaveChanges()). Тоже наплевать (так же, как и на help)?

← →
sniknik (2003-03-07 20:30) [104]

ki11er (07.03.03 17:41)
> Еще раз смотрим вот сюда:
в свою очередь посмотри еще раз сюда -> sniknik © (07.03.03 17:00)
вижу остался не понятым. ладно попытаюсь еще раз (last time) другими словами. в общем так, делаеш 2 потока в каждом по запросу (ну чем ты уже хвастался), запускаеш одновременно и ждеш завершения последнего, засекаеш время и смотриш сколько прошло.
второй этап запускаеш эти же запросы последовательно без потоков (в основном) последовательно. Засеки прошедшее время и сравни с потоковым методом. Теоретически в потоке будет потрачено больше времени на выполнение (неуверен только будет это видно на 2х потоках) разница будет тем больше чм больше будет задействовано потоков, т.к. квантование и распределение "тиков" между потоками тоже требует ресурсов.
(надеюсь засекать будеш не по будильнику :-)))

> про стопроцентную нагрузку никто не говорит, это вообще не реализуемо...
тогда какая тебе разница?
судя по пункту
(> 7. Теперь о том, что должна программа в этом режиме делать. С многоканального оборудования асинхронно поступают данные, которые должны заноситься в таблицу достаточно быстро, иначе могут потеряться (при выполнении только этой задачи - запас по времени достаточно большой). .....)
интенсивность поступающих данных велика, и вся бодяга с потоками затеяна ради ускорения записи в базу. А тебе уже в который раз пытаются доказать что ускорения не будет.
и единственное что нужно это грамотно организовать очередь, буфер или чтото подобное.

← →
ki11er (2003-03-07 21:18) [105]

> Как происходит взаимодействие с визуальными компанентами
> твоих потоков?

Никак...

← →
Mike Kouzmine (2003-03-07 21:30) [106]

Если сделать Post, а затем FlushBuffers, то выдается ошибка.
Надо или Flush или Post

← →
ki11er (2003-03-07 21:31) [107]

2 sniknik:
Неа... Не надо меня путать ;-) Суммарное время выполнения конечно же будет больше (при параллельном, сорри, забыл - псевдо параллельном, а то опять начнется...). Но! Критический по времени поток запишет данные пусть за 3 секунды вместо 2 параллельно с выполнением некритического. А не будет ждать условно говоря полчаса пока некритический что-то сделает. Улавливаешь в чем разница? ;-)))

← →
Mike Kouzmine (2003-03-07 21:35) [108]

Соврал

← →
ki11er (2003-03-07 21:35) [109]

> Если сделать Post, а затем FlushBuffers, то выдается ошибка.

Никаких ошибок быть не должно - у Вас что-то не так написано.
Post и Flush несколько разные вещи... Кстати, что за ошибка?

← →
sniknik (2003-03-07 21:51) [110]

Критический это надо полагать запись от прибора, некритический это так сказать запрос от пользователя?

вот и делай 2 потока критический /запись и некритический /чтение юзером. Что уже не раз предлагалось. (и мной в том числе)

все на этом завязываю. т.к. полагаю что ты чтото вроде мазахиста, тебя вроде как уламывают а ты оказывается все с самого начала знал, но не соглашался вроде из принципа но прочтение ветки показывает что это не так, только пальцы гнеш.
(сказал бы это в начале, 2/3 флейма бы не было, но ты это отрицал)
пока.

p.s. нику ki11er больше не отвечаю, бессмысленно, знает больше всех на форуме вместе взятых, но почемуто вые%:&ся. (сарказм) если же это не так и чегото всетаки подчерпнул то тогда просто неблагодарная скотина.

← →
Serginio (2003-03-07 21:58) [111]

Не согласен с (sniknik ©) и делая доступ (чтение) к FoxPro Filesan Файлоф 1С в разных сочетаниях как последовтельных так и паралельных. И время одновременных обращениях к БД на уровне курсоров одинаково. Скорей всего проблема заключается в том, что каждый поток забирает очень много ресурсов хотя у меня не встречалось. Есть опыт работы через DCOM и TSocketConnrctinon нужно проследить где слабое место.

А для записи (sniknik © прав однозначно) для локальных баз Используй MultiReadWriteIsclusive или его аналги(Это не SQL). Это правильно.

← →
ki11er (2003-03-07 22:01) [112]

> вот и делай 2 потока критический /запись и некритический
> /чтение юзером. Что уже не раз предлагалось. (и мной в том
> числе)

8-O Так так и сделано 8-O
А предлагалось мне (не тобой, - другими) "забыть про потоки" и т.п. - почитай выше?! Я уже перестаю вообще что-то понимать 8-O

> тебя вроде как уламывают а ты оказывается все с самого начала
> знал, но не соглашался вроде из принципа но прочтение ветки
> показывает что это не так, только пальцы гнеш.
> (сказал бы это в начале, 2/3 флейма бы не было, но ты это
> отрицал)

Не понимаю, о чем ты? Кто уламывает? С чем не соглашаюсь? Какие пальцы?

Мдааа...... 8-(

← →
ki11er (2003-03-07 22:06) [113]

sniknik © (07.03.03 17:00):
(писал уже в грохнутой ветке)
можно организовать очередь из сообщений, в принципе ничего терятся не должно.

многопоточный вариант записи в базу, только затормозит процесс, что скорее приведет к потере данных. (оптимум 2 потока 1 на запись и 1 на чтение, было бы ADO то 2 асинхронно работающих компонента)
время выполнения 2х потоков

sniknik © (07.03.03 21:51):
вот и делай 2 потока критический /запись и некритический /чтение юзером. Что уже не раз предлагалось. (и мной в том числе)

Это я накануне праздника перепил или все-таки не я? ;-)))

← →
MsGuns (2003-03-07 22:10) [114]

Есть мысли, но в эту ветку не буду отвечать из принципа.
Завели новую, там будет все как бы с нуля. Не смотри на модноратора :))) - это вполне нормальные челы ;)))

← →
sniknik (2003-03-08 00:02) [115]

видиш только то что хочеш, не пытаясь понять, а без понимания нет разговора, есть бессмысленный спор.

ki11er (07.03.03 22:06)
sniknik © (07.03.03 17:00):
(писал уже в грохнутой ветке)
можно организовать очередь из сообщений, в принципе ничего терятся не должно.

многопоточный вариант записи в базу, только затормозит процесс, что скорее приведет к потере данных. ( оптимум 2 потока 1 на запись и 1 на чтение, было бы ADO то 2 асинхронно работающих компонента)
время выполнения 2х потоков

sniknik © (07.03.03 21:51):
вот и делай 2 потока критический /запись и некритический /чтение юзером. Что уже не раз предлагалось. (и мной в том числе)

Это я накануне праздника перепил или все-таки не я? ;-)))

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

← →
Serginio (2003-03-11 12:11) [116]

Протрезвел.
1. Используй MultiReadExclusiveWriteSinchronize.
Или LockTable.
Дело в том, что при записи в локальную таблицу происходит как запись в таблицу, так и перестроение индекса. А когда несколько потоков начинают одновременно индексировать (Типичные Б Деревья) вот ты и получаешь все выше перечисленные проблемы.

← →
ki11er (2003-03-11 14:40) [117]

2 MsGuns:
пиши сюда:
http://delphi.mastak.ru/cgi-bin/forum.pl?look=1&id=1047032189&n=1

2 sniknik:
Ok. Давайте определимся с понятиями, чтобы в дальнейшем не путаться:
многопоточный - количество потоков > 1.
поток записи - поток, который пишет в таблицу новые записи или модифицирует старые.
поток чтения - поток, который только читает из таблицы.

2 Serginio:
Я уже склоняюсь, к тому, чт возможно так и придется сделать. Но почему это не сделано на уровне ядра BDE? Или все-таки сделано, но нужно знать как правильно с этим работать? У кого есть Аргументированный ответ?

← →
app (2003-03-11 14:42) [118]

ki11er (11.03.03 14:40)

2 MsGuns:
И не пытайся

← →
Serginio (2003-03-11 14:57) [119]

Однозначно BDE не следит за записями в файл т. к. у тебя реализован многопользовательский доступ (Может и возможно но скорее нет когда ты реализуешь Eксклюзивный доступ через клонирование курсоров). Для этого и существует LockTable.
Даже если ты MultiReadExclusiveWriteSinchronize ты должен быть уверен, что к таблице никто не подключен с другого компьютера или процесса.

← →
ki11er (2003-03-11 16:31) [120]

2 Serginio:

> Однозначно BDE не следит за записями в файл

Где это написано?

---|Ветка была без названия|--- Найти похожие ветки