Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: < 1 2 3 4 5 6 7 8 >
ki11er © (2003-03-04 21:11:00)
приведенный ниже код валится через пару минут работы с сообщениями "Index is out of date" или "Insufficient Memory..." (при 256 оперативки и паре свободных гигах на винте ;-))))
При написании следовал советам, полученным в этой конференции, а так же из других источников. Можно ли написать подобный код так, чтобы он работал без глюков или это принципиально невозможно?

procedure TFormMain.FormCreate(Sender: TObject);
var i: integer;
str_tmp: string;
begin
StartDir := ExtractFilePath(Application.ExeName);
if StartDir[Length(StartDir)] <> "\" then begin
StartDir := StartDir + "\";
end;
sDirDB := StartDir + "dbase\";
CreateDir(sDirDB);
CreateDir(StartDir + "net");
Session.NetFileDir := StartDir + "net";
CreateDir(StartDir + "private");
str_tmp := StartDir + "private\" + IntToStr(GetTickCount);
CreateDir(str_tmp);
Session.PrivateDir := str_tmp;

tbTest.DatabaseName := sDirDB;
qrTest.DatabaseName := sDirDB;

btnStartStop.Caption := "

Serginio (2003-03-11 17:30:00) [21]
BDE тебе дает доступ (запись,чтение) к файлам через драйверы Paradox и больше ничего. Все остальное делается на уровне файлов (Открытие Эксклюзивно (OpenFile с флагом OF_SHARE_EXCLUSIVE), LockFile). А вот если ты сам будешь следить ты можешь получить клиент-сервер на локальных БД.

ki11er (2003-03-11 16:31:00) [22]
2 Serginio:

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

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

Serginio (2003-03-11 14:57:00) [23]
Однозначно BDE не следит за записями в файл т. к. у тебя реализован многопользовательский доступ (Может и возможно но скорее нет когда ты реализуешь Eксклюзивный доступ через клонирование курсоров). Для этого и существует LockTable.
Даже если ты MultiReadExclusiveWriteSinchronize ты должен быть уверен, что к таблице никто не подключен с другого компьютера или процесса.

app (2003-03-11 14:42:00) [24]
ki11er (11.03.03 14:40)

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

ki11er (2003-03-11 14:40:00) [25]
2 MsGuns:
пиши сюда:
http://delphi.mastak.ru/cgi-bin/forum.pl?look=1&id=1047032189&n=1

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

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

Serginio (2003-03-11 12:11:00) [26]
Протрезвел.
1. Используй MultiReadExclusiveWriteSinchronize.
Или LockTable.
Дело в том, что при записи в локальную таблицу происходит как запись в таблицу, так и перестроение индекса. А когда несколько потоков начинают одновременно индексировать (Типичные Б Деревья) вот ты и получаешь все выше перечисленные проблемы.

sniknik (2003-03-08 00:02:00) [27]
видиш только то что хочеш, не пытаясь понять, а без понимания нет разговора, есть бессмысленный спор.

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-ти ассоциация.

MsGuns (2003-03-07 22:10:00) [28]
Есть мысли, но в эту ветку не буду отвечать из принципа.
Завели новую, там будет все как бы с нуля. Не смотри на модноратора :))) - это вполне нормальные челы ;)))

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

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

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

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

ki11er (2003-03-07 22:01:00) [30]

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

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

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

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

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

Serginio (2003-03-07 21:58:00) [31]
Не согласен с (sniknik ©) и делая доступ (чтение) к FoxPro Filesan Файлоф 1С в разных сочетаниях как последовтельных так и паралельных. И время одновременных обращениях к БД на уровне курсоров одинаково. Скорей всего проблема заключается в том, что каждый поток забирает очень много ресурсов хотя у меня не встречалось. Есть опыт работы через DCOM и TSocketConnrctinon нужно проследить где слабое место.

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

sniknik (2003-03-07 21:51:00) [32]
Критический это надо полагать запись от прибора, некритический это так сказать запрос от пользователя?

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

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

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

Mike Kouzmine (2003-03-07 21:35:00) [33]
Соврал

ki11er (2003-03-07 21:35:00) [34]

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

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

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

Mike Kouzmine (2003-03-07 21:30:00) [36]
Если сделать Post, а затем FlushBuffers, то выдается ошибка.
Надо или Flush или Post

ki11er (2003-03-07 21:18:00) [37]

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

Никак...

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

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

ki11er (2003-03-07 19:51:00) [39]

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

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

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

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

Mike Kouzmine (2003-03-07 19:03:00) [40]
Потом actcount - это глобальная переменная? В нее пишут все потоки?
Как происходит взаимодействие с визуальными компанентами твоих потоков?

Страницы: < 1 2 3 4 5 6 7 8 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »