![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
---|Ветка была без названия|---
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 := "
ki11er (2003-03-06 13:01:00) [101]2 MsGuns:
> В сабже указано четко - формат Парадокс. Локалка в натуральном
> виде ! Это априори чисто КЛИЕНТСКИЙ ПОДХОД.
> Объяснять разницу между локальной и клиент-серверной БД
> и, соответственно, ОГРОМЕННУЮ разницу в реализации доступа
> к данным ?
Я Вы не путаете понятия "клиент", "сервер", "технология клиент-сервер" ?
> Так вся эта по@#$нь спокойно реализуется в контексте ЕДИНСТВЕННОЙ
> Default-сессии (надо рассказывать, что ее не надо ни криэйтить,
> ни убивать или ты это все-таки прочитал ?)
> Для ее реализации надо 3 DataSeta (каких, в принципе роли
> для парадокса не играет):
Т.е. на то, что написано в хэлпе наплевать? Я правильно понял?
> Да хоть 20 юзеров - на разных машинах НЕ МОЖЕТ БЫТЬ ОДНОГО
> ПОТОКА ФИЗИЧЕСКИ !!! А БД все равно будет обрабатывать запросы
> ПОСЛЕДОВАТЕЛЬНО !!!!!!!!!!!!
;-O Серьезно? А как тогда Вы мне обясните, что одновременно с выполнением нескольких (или пусть одного) запросов через TQuery идет и запись в таблицу. Если бы все так просто было, я бы поставил крит секцию и спал бы спокойно ;-)))
> Поверь, для решения этой траблы потоки и на фиг не нужны
> !
Я все-таки не догнал. Это извиняюсь как? Работает допустим, какой-то станок, поддходик к компу юзер, тыкает кнопку "Сформировать мне отчет за прошлый год с раскладкой по месяцам 20 параметров и т.д. и т.п.". При этом в соответствии с вашими мыслями приостанавливается точение болванки (это в лучшем случае) и начинает формироваться отчет. Я все правильно понимаю?
> Уважаемый киллер ! Кто-то, возможно книги и хэлпы, набили
> тебе голову этими потоками. Забудь о них на время ! Будет
> сразу проще жить ! И запомни простой постулат ЧЕМ ПРОЩЕ,
> ТЕМ ЛУЧШЕ !
Ну что тут можно сказать?! Не могли бы Вы привести примеры проектов, которые Вам приходилось разрабатывать? Для BlackTiger тот же вопрос.
Похоже, ребята, я с вами просто теряю время :-( Да в базах я не силен, но не надо мне рассказывать про процессы, потоки и тому подобные вещи. А тем более говорить такие глупости (думаю, в данном случае это уже не является невежливостью).
PS. Просьба, если нечего сказать по существу, не захломляйте тред, он уже и так длинный ;-)))
BlackTiger (2003-03-06 01:07:00) [102]2MsGuns
:))) Вот и я о том же! Начитаются всякой ерунды - многопоточность-многозадачность, мутексы-шмутексы, комы-дкомы и другой хр... фигни, потом делают все через... пути неисповедимые. И удивляются - почему это у них все работает "не так"? Эти мне "продвинутые"...
Гвозди электронным микроскопом тоже можно забивать, но молотком - оно по-проще...
Многопоточность (как мультизадачность) в системах "нереального" времени - хохма, придуманная хохмачами. Правда сейчас это модно, статеек в нете лежит много. Вот народ и думает, что "это хорошо".
MsGuns (2003-03-05 22:11:00) [103]Попробую в последний раз.
>Во-первых, я разве говорил, что это клиентское приложение? Тыкните носом, где?
В сабже указано четко - формат Парадокс. Локалка в натуральном виде ! Это априори чисто КЛИЕНТСКИЙ ПОДХОД.
Объяснять разницу между локальной и клиент-серверной БД и, соответственно, ОГРОМЕННУЮ разницу в реализации доступа к данным ?
>Чтобы наконец остановить поток подобных вопросов и замечаний, вот пример из жизни:
Пусть есть некоторая железяка, с которой поступают асинхронно некоторые данные. Пусть частота поступления данных колеблется в пределах 20-80 секунд. Эти данные ложатся в таблицу. Параллельно с этим работает поток, который выбирает из этой таблицы данные по некоторым критериям посредством SQL-запроса, который выполняется например 1 минуту с индексами и 50 минут без индексов. Плюс есть локальный пользователь, который хочет просмотреть часть (отфильтрованную с помощью SQL-запроса) таблицы и возможно что-то в ней изменить, если захочет. Плюс есть точно такой же удаленный (пусть по локалке для простоты) юзер. Плюс есть поток, который просматривает таблицу, находит в ней по каким-то критериям записи и модифицирует их.
Наконец-то хоть намек на что-то конкретное !
Так вся эта по@#$нь спокойно реализуется в контексте ЕДИНСТВЕННОЙ Default-сессии (надо рассказывать, что ее не надо ни криэйтить, ни убивать или ты это все-таки прочитал ?)
Для ее реализации надо 3 DataSeta (каких, в принципе роли для парадокса не играет):
>Пусть есть некоторая железяка, с которой поступают асинхронно некоторые данные. Пусть частота поступления данных колеблется в пределах 20-80 секунд. Эти данные ложатся в таблицу
Датасет (допустим, TQuery), который откуда-то "берет" раскодированные аналоговые данные и добавляет их ПО ОДНОЙ в таблицу БД TABLE
>Параллельно с этим работает поток, который выбирает из этой таблицы данные по некоторым критериям посредством SQL-запроса, который выполняется например 1 минуту с индексами и 50 минут без индексов.
Датасет (допустим, TQuery), который попеременно, в зависимости от каких-то внешних факторов (например, таймера), выполняет выборку по каким-то условиям (нужны или нет при этом индексы для ускорения - второй вопрос) и куда-то эти результаты отправляет.
>Плюс есть локальный пользователь, который хочет просмотреть часть (отфильтрованную с помощью SQL-запроса) таблицы и возможно что-то в ней изменить, если захочет.
3.Датасет (допустим, TTable), который отображается в гриде и который может просматривать или править один или несколько узеров.
PS
>Плюс есть точно такой же удаленный (пусть по локалке для простоты) юзер
Да хоть 20 юзеров - на разных машинах НЕ МОЖЕТ БЫТЬ ОДНОГО ПОТОКА ФИЗИЧЕСКИ !!! А БД все равно будет обрабатывать запросы ПОСЛЕДОВАТЕЛЬНО !!!!!!!!!!!!
Для сложности интересно посмотреть как ты собираешься юзать Парадокс не по локалке. Через сокеты ?
>Плюс есть поток, который просматривает таблицу, находит в ней по каким-то критериям записи и модифицирует их.
Ничего не надо, т.к. в природе не существует задач, которые "что-то делают для чего-то"
Для 3-го запроса (и только для него !) надо периодически рефрешить НД, чтобы узер видел все изменения. Если надо "мгновенное" отражение внесенных им изменений, то либо отключать буферирование, либо "сбрасывать" изменения в каждом AfterDelete/Post/Insert (FlushBuffers).
Поверь, для решения этой траблы потоки и на фиг не нужны !
И еще раз повторюсь: для НАДЕЖНОЙ и БЫСТРОЙ работы подобного приложения при достаточно большом объеме данных, да еще при нескольких одновременно работающих узерах ПАРАДОКС НЕ ГОДИТСЯ по-любому.
Уважаемый киллер ! Кто-то, возможно книги и хэлпы, набили тебе голову этими потоками. Забудь о них на время ! Будет сразу проще жить ! И запомни простой постулат ЧЕМ ПРОЩЕ, ТЕМ ЛУЧШЕ !
ki11er (2003-03-05 21:42:00) [104]
> Уважаемый ki11er! Во-первых, попрошу запомнить одну элементарную
> вещь - НЕТ РЕАЛЬНОЙ МНОГОПОТОЧНОСТИ НА ОДНО-ПРОЦЕССОРНОЙ
> МАШИНЕ!!!
> Все есть простая эмуляция через квантование (20 мсек).
и истинное знание нам недоступно, ибо познанная истина ...
;-)))))))))))))))))
> В-третьих, за 10 лет программирования НИ РАЗУ не приходилось
> использовать многопоточность в КЛИЕНТСКИХ приложениях.
Во-первых, я разве говорил, что это клиентское приложение? Тыкните носом, где?
Во-вторых, если Вам не приходилось, это еще не значит, что никому не приходилось, не приходится и не придется.
MSSQL, Oracle, ADO и прочие подобные вещи - обсуждайте в другой ветке. Я не спорю и никогда не спорил, что все это круто. Но к обсуждаемой проблеме не имеет никакого отношения.
> З.Ы. (без обид) А "пример" действительно дурацкий, и не
> имеющий применения в реальной жизни.
Обид никаких...
Чтобы наконец остановить поток подобных вопросов и замечаний, вот пример из жизни:
Пусть есть некоторая железяка, с которой поступают асинхронно некоторые данные. Пусть частота поступления данных колеблется в пределах 20-80 секунд. Эти данные ложатся в таблицу. Параллельно с этим работает поток, который выбирает из этой таблицы данные по некоторым критериям посредством SQL-запроса, который выполняется например 1 минуту с индексами и 50 минут без индексов. Плюс есть локальный пользователь, который хочет просмотреть часть (отфильтрованную с помощью SQL-запроса) таблицы и возможно что-то в ней изменить, если захочет. Плюс есть точно такой же удаленный (пусть по локалке для простоты) юзер. Плюс есть поток, который просматривает таблицу, находит в ней по каким-то критериям записи и модифицирует их.
Достаточно? Или развить тему дальше?
ЛЮДИ! Давайте не будем выяснять, зачем, а? Лучше давайте сконцентрируемся на поиске проблемы.
Без обид ;-)))
ki11er (2003-03-05 21:33:00) [105]
> Уважаемый ki11er! Во-первых, попрошу запомнить одну элементарную
> вещь - НЕТ РЕАЛЬНОЙ МНОГОПОТОЧНОСТИ НА ОДНО-ПРОЦЕССОРНОЙ
> МАШИНЕ!!!
> Все есть простая эмуляция через квантование (20 мсек).
и истинное знание нам недоступно, ибо познанная истина ...
;-)))))))))))))))))
> В-третьих, за 10 лет программирования НИ РАЗУ не приходилось
> использовать многопоточность в КЛИЕНТСКИХ приложениях.
Во-первых, я разве говорил, что это клиентское приложение? Тыкните носом, где?
Во-вторых, если Вам не приходилось, это еще не значит, что никому не приходилось, не приходится и не придется.
MSSQL, Oracle, ADO и прочие подобные вещи - обсуждайте в другой ветке. Я не спорю и никогда не спорил, что все это круто. Но к обсуждаемой проблеме не имеет никакого отношения.
BlackTiger (2003-03-05 20:14:00) [106]Влезу-ка я в эту "дискуссию".
Уважаемый ki11er! Во-первых, попрошу запомнить одну элементарную вещь - НЕТ РЕАЛЬНОЙ МНОГОПОТОЧНОСТИ НА ОДНО-ПРОЦЕССОРНОЙ МАШИНЕ!!!
Все есть простая эмуляция через квантование (20 мсек).
Во-вторых, если более подробнее поинтересоваться многопоточными DB-приложениями, то видно, что это оправдано ТОЛЬКО при длительных по времени запросах, чтобы во время ожидания выполнять еще какие-либо действия (есссесно с потерей производительности).
В-третьих, за 10 лет программирования НИ РАЗУ не приходилось использовать многопоточность в КЛИЕНТСКИХ приложениях.
В-четвертых, вся эта байда не имеетсмысла при работе с базами данных, которые имеют ограничение на количесво конкурирующих сессий (MSSQL,Oracle).
В-пятых, в АДО используется асинхронность запросов, а не многопоточность.
З.Ы. (без обид) А "пример" действительно дурацкий, и не имеющий применения в реальной жизни.
ki11er (2003-03-05 18:57:00) [107]
> В описании задачи не описал самое главное: КАК будкт добавляться/удаляться/изменяться
> записи
> -юзерами с одной или нескольких ПК
> -пакетно из других таблиц
> -на основании других источников
Так как это тест, то никаких юзеров не будет. добавляться/удаляться/изменяться будет соответствующими потоками (их поведение задается жестко при старте программы или в соответствии с настройками при нажатии кнопки "пуск". Например, первый, второй и третий добавляют случайно сгенеренные записи, четвертый - удаляет случайным образом выбранные записи и т.д.) Для простоты пусть только одна копия программы на локальном компьютере и таблица здесь же, на локальном диске.
2 sniknik:
> Удастся возвращайся сюда еще поспорить.
Думаю, что удастся, но ради очистки совести сейчас попробую...
> Я лично делаю ставку на то что у тебя запущеных будет гдето
> 7-8, не больше.
И какого размера ставка? ;-)))
А если серьезно, пусть будет даже 7, но _стабильно_работающих_ потока. Ограничение на количество я еще могу понять. Но пока что и 2 падают ;-(((
sniknik (2003-03-05 17:51:00) [108]ki11er (05.03.03 16:34)
> 2. Из N потоков выполнять асинхронно добавление, изменение, удаление записей из одной таблицы через компонент TTable.
> 3. Из M потоков выполнять асинхронно добавление, изменение, удаление записей из одной таблицы через компонент TQuery.
> А однопоточные варианты меня мало интересуют. ;-)
зря надо бы чтобы интересовали (от простого к сложному так сказать),
сделай ПРОСТОЕ приложение, ну чтобы ничего не делало просто открывало 1 таблицу через BDE (из текушего пути), после раскопируй в 11 разных мест (чтобы таблици разные открывались) и запусти все. Удастся возвращайся сюда еще поспорить. Я лично делаю ставку на то что у тебя запущеных будет гдето 7-8, не больше.
MsGuns (2003-03-05 17:31:00) [109]В описании задачи не описал самое главное: КАК будкт добавляться/удаляться/изменяться записи
-юзерами с одной или нескольких ПК
-пакетно из других таблиц
-на основании других источников
Вот это и концептуально для выбора многопоточности.
В целом же для соблюдения П.5 BDE и особенно парадокс мало подходят. В SQL-серверном приложении потки в том смысле, что ты описал, выполняются не в приложении, а самим сервером. Посему разработчику надо лишь правильно прописать логику серверной части БД. Клиент же просто "делает, что хочет", не думая о том, что кто-то еще "лапает" его таблицы.
ki11er (2003-03-05 16:34:00) [110]
> Хамством такое замечание назвать было бы неверно, а вот
> невежлтвостью - однозначно. Если обращаемся к конкретному
> лицу, то воспитанные люди не употребляют силлогизмов типа
> "Тот, который" или "Тому, кто сказал".
Согласен и с тем и с другим. Просто при такой оживленной дискуссии сложно держать в голове кто, что сказал ;-)
> По поводу TDatabase. Судя по всему, опыта и понимания принципов
> работы БД у тебя маловато. Имеется в виду прежде всего практический
> опыт, а не вычитанные из хелпов и принятые за руководство
> к действию фрагменты. Это я не к тому, чтобы "осадить",
> а к тому, что прежде чем начать реально программировать
> МНОГОПОТОЧНЫЕ обращения к БД, желательно более-менее разобраться
> с однопоточными. Может потом и необходимость в параллировании
> (а именно для этой цели, еще иногда называемой асинхронизацией,
> используются разные сессии) и отпадет.
> Если уж используешь BDE, то начни с ВНИМАТЕЛЬНОГО изучения
> свойств, методов и событий, а также иерархии классов, соотв.
> Borland`ских компонент. Рекомендую такую посл-ть:
>
> -TSession
> -TDatabase
> -TTable
> -TQuery
> -TBatchMove
>
> и их предков: TDataSet, TDBDataSet, TBDEDataSet
>
> а так же TField, TFieldDefs, TFieldDef
>
> Я думаю, что после того, как эти вещи будут достаточно исследованы
> (именно исследованы, а не просмотрены), ты сам прекрасно
> ответишь на все свои вопросы.
Именно с этого я и начал ;-) Сначала изучил все, что мне было доступно. Потом написал код. Потом написал сюда ;-)
По-моему, вопрос достаточно конкретен. Мне не хотелось бы до бесконечности отвечать на "зачем?", "почему?", "для чего?" и т.п.
Вот код. Он не работает. Противоречий с документацией я не нахожу. Отсюда вопрос либо документация не правильная, либо я чего-то упустил... Поэтому и прошу помощи. Неужели данный вопрос никому не интересен?
Задача в целом такая:
1. Delphi, BDE, Paradox, таблица с индексами (первичный и несколько вторичных)
2. Из N потоков выполнять асинхронно добавление, изменение, удаление записей из одной таблицы через компонент TTable.
3. Из M потоков выполнять асинхронно добавление, изменение, удаление записей из одной таблицы через компонент TQuery.
4. 2 и 3 одновременно.
5. Программа должна работать без сбоев при условии, что компьютер не выключают при работающей программе.
А однопоточные варианты меня мало интересуют. ;-)
С уважением.
MsGuns (2003-03-05 15:52:00) [111]>ki11er (05.03.03 14:18)
>Повторю вопрос тому, кто это предложил - так нужен он или нет? И если нужен, то для чего?
Хамством такое замечание назвать было бы неверно, а вот невежлтвостью - однозначно. Если обращаемся к конкретному лицу, то воспитанные люди не употребляют силлогизмов типа "Тот, который" или "Тому, кто сказал".
Я не могу привести кода по той причине, что не умею писать проги, не зная ЧТО они должны делать.
По поводу TDatabase. Судя по всему, опыта и понимания принципов работы БД у тебя маловато. Имеется в виду прежде всего практический опыт, а не вычитанные из хелпов и принятые за руководство к действию фрагменты. Это я не к тому, чтобы "осадить", а к тому, что прежде чем начать реально программировать МНОГОПОТОЧНЫЕ обращения к БД, желательно более-менее разобраться с однопоточными. Может потом и необходимость в параллировании (а именно для этой цели, еще иногда называемой асинхронизацией, используются разные сессии) и отпадет.
Если уж используешь BDE, то начни с ВНИМАТЕЛЬНОГО изучения свойств, методов и событий, а также иерархии классов, соотв. Borland`ских компонент. Рекомендую такую посл-ть:
-TSession
-TDatabase
-TTable
-TQuery
-TBatchMove
и их предков: TDataSet, TDBDataSet, TBDEDataSet
а так же TField, TFieldDefs, TFieldDef
Я думаю, что после того, как эти вещи будут достаточно исследованы (именно исследованы, а не просмотрены), ты сам прекрасно ответишь на все свои вопросы.
С уважением.
MsGuns (2003-03-05 15:51:00) [112]>ki11er (05.03.03 14:18)
>Повторю вопрос тому, кто это предложил - так нужен он или нет? И если нужен, то для чего?
Хамством такое замечание назвать было бы неверно, а вот невежлтвостью - однозначно. Если обращаемся к конкретному лицу, то воспитанные люди не употребляют силлогизмов типа "Тот, который" или "Тому, кто сказал".
По поводу TDatabase. Судя по всему, опыта и понимания принципов работы БД у тебя маловато. Имеется в виду прежде всего практический опыт, а не вычитанные из хелпов и принятые за руководство к действию фрагменты. Это я не к тому, чтобы "осадить", а к тому, что прежде чем начать реально программировать МНОГОПОТОЧНЫЕ обращения к БД, желательно более-менее разобраться с однопоточными. Может потом и необходимость в параллировании (а именно для этой цели, еще иногда называемой асинхронизацией, используются разные сессии) и отпадет.
Если уж используешь BDE, то начни с ВНИМАТЕЛЬНОГО изучения свойств, методов и событий, а также иерархии классов, соотв. Borland`ских компонент. Рекомендую такую посл-ть:
-TSession
-TDatabase
-TTable
-TQuery
-TBatchMove
и их предков: TDataSet, TDBDataSet, TBDEDataSet
а так же TField, TFieldDefs, TFieldDef
Я думаю, что после того, как эти вещи будут достаточно исследованы (именно исследованы, а не просмотрены), ты сам прекрасно ответишь на все свои вопросы.
С уважением.
ki11er (2003-03-05 15:50:00) [113]Неужели здесь не найдется человека, способного пролить свет на данный вопрос ? :-(((((((((((((((((((((((((((
ki11er (2003-03-05 14:18:00) [114]Единственный более-менее дельный совет из всей этой полемики - про TDatabase как-то замялся. Повторю вопрос тому, кто это предложил - так нужен он или нет? И если нужен, то для чего?
ki11er (2003-03-05 14:15:00) [115]
> Учимся читать, а не копировать!
> For session components other than the default session, an
> application should call Free, which verifies that the session
> component is not nil before calling Destroy.
Да, конечно. Сорри, погорячился. Но опять же это не важно в данном случае. Допустим никогда не разрушаются (хотя на самом деле разрушаются) - я запустил программу и пусть работает бесконечно (чего я и хочу добиться) ;-)
ki11er (2003-03-05 14:11:00) [116]
> Eto hamstvo.
Не совсем так. Я мог бы сказать, что Session у меня - член класса и в соответствии с принципами ООП (да и не только ООП) именно он (а не глобальный) будет использоваться при выполнении тех операций, о которых шла речь.
ki11er (2003-03-05 14:05:00) [117]
> Оно МОЖЕТ работать в принципе. Но зачем ездить с квадратными
> колесами ? А уж если это делать, то совсем не так безбашенно,
> как в приведенном коде.
Мда... интересное заявление. Еще рарз повторюсь, это придумал не я все сделано в соответствии с хэлпами. Если Вы где-то углядели несоответствие - буду рад, если Вы на него укажете. С удовольствием протестирую Ваш вариант код (только он должен делать то же самое теми же самыми средствами). Если он (Ваш код) будет более стабилен, опять же буду только рад и премного благодарен.
Anatoly Podgoretsky (2003-03-05 14:03:00) [118]Учимся читать, а не копировать!
For session components other than the default session, an application should call Free, which verifies that the session component is not nil before calling Destroy.
ki11er (2003-03-05 13:58:00) [119]
> В справке по этой переменной и соотв.компоненте так и написано,
> что разработчик сам несет всю ответственность за создание
> и уничтожение созданных им сессий.
Это интересно в какой справке? В моей так написано:
Creates an instance of a TSession component.
Delphi syntax:
constructor Create(AOwner: TComponent);
Description
Do not call Create directly. The default session component, Session, is created automatically for all database applications. To create additional sessions for a multi-threaded database application at runtime call Sessions.OpenSession instead of Create. OpenSession calls Create only if the session does not already exist. (At design time, create additional sessions by dropping them on a data module.)
Destroys the instance of a session component.
Delphi syntax:
destructor Destroy;
Description
Do not call Destroy directly. For session components other than the default session, an application should call Free, which verifies that the session component is not nil before calling Destroy.
MsGuns (2003-03-05 13:57:00) [120]>ki11er (05.03.03 13:49)
>Имеется в виду, что на связке Delphi+BDE+Paradox это принципиально не должно работать?
Оно МОЖЕТ работать в принципе. Но зачем ездить с квадратными колесами ? А уж если это делать, то совсем не так безбашенно, как в приведенном коде.
>Тогда почему в хэлпах пишут, что должно?
В хэлпах такого не пишут. Читай внимательнее. Пользуйся словарем для выбора всего спектра переводов слова, ТОЧНОГО смысла которого тебе не известно в данном контексте.