Запросы, планы, оптимизация запросов, ...
Модераторы: kdv, CyberMax
-
ArtDen
- Сообщения: 53
- Зарегистрирован: 25 ноя 2007, 10:54
Сообщение
ArtDen » 16 мар 2009, 11:55
Привет всем. В описании ODBC драйвера про многопоточность написано:
Default: The driver is built using the following define:
#define DRIVER_LOCKED_LEVEL DRIVER_LOCKED_LEVEL_CONNECT
then a single connection can share multiple local threads.
Хочу уточнить: это означает, что я могу в одном потоке создать SQL_HANDLE_ENV и SQL_HANDLE_DBC, а в другом потоке использовать SQL_HANDLE_STMT?
И ещё. Можно ли для одного SQL_HANDLE_DBC в разных потоках одновременно использовать несколько SQL_HANDLE_STMT? Если да, то как они будут обрабатываться - параллельно или последовательно.
PS: под SQL_HANDLE_ENV, SQL_HANDLE_DBC и SQL_HANDLE_STMT я подразумеваю odbc-хендлы созданные с этими типами.
-
kdv
- Forum Admin
- Сообщения: 6595
- Зарегистрирован: 25 окт 2004, 18:07
Сообщение
kdv » 18 мар 2009, 16:39
Вы вообще о каком драйвере, и про какую именно "многопоточность"?
-
kdv
- Forum Admin
- Сообщения: 6595
- Зарегистрирован: 25 окт 2004, 18:07
Сообщение
kdv » 19 мар 2009, 15:19
imho, все это муйня. клиентская часть допускает работу с одним коннектом только в одном треде.
Любые альтернативные движения до версии клиента FB 2.5 надо делать с синхронизацией, что ликвидирует смысл подобной "мультитредовости". Впрочем, в клиенте 2.5 всего-лишь не будет глюков, но многопоточности в одном коннекте все равно не будет (как ее нет ни у одной СУБД).
-
ArtDen
- Сообщения: 53
- Зарегистрирован: 25 ноя 2007, 10:54
Сообщение
ArtDen » 20 мар 2009, 09:04
kdv писал(а):imho, все это муйня. клиентская часть допускает работу с одним коннектом только в одном треде.
Любые альтернативные движения до версии клиента FB 2.5 надо делать с синхронизацией, что ликвидирует смысл подобной "мультитредовости". Впрочем, в клиенте 2.5 всего-лишь не будет глюков, но многопоточности в одном коннекте все равно не будет (как ее нет ни у одной СУБД).
С этим всё ясно. Другого я и не ожидал
Осталось только выяснить: могу ли в одном потоке создать SQL_HANDLE_ENV и SQL_HANDLE_DBC (подключиться к odbc-драйверу и базе данных), и в другом (одном и только одном!) потоке использовать SQL_HANDLE_STMT (выполнять sql-запросы)?
-
kdv
- Forum Admin
- Сообщения: 6595
- Зарегистрирован: 25 окт 2004, 18:07
Сообщение
kdv » 20 мар 2009, 10:18
Осталось только выяснить: могу ли в одном потоке создать SQL_HANDLE_ENV и SQL_HANDLE_DBC (подключиться к odbc-драйверу и базе данных), и в другом (одном и только одном!) потоке использовать SQL_HANDLE_STMT (выполнять sql-запросы)?
поскольку ODBC работает с сервером не волшебным образом, а через fbclient.dll, то такое не будет глючить только с клиентом FB 2.5. Пробуйте.
-
ArtDen
- Сообщения: 53
- Зарегистрирован: 25 ноя 2007, 10:54
Сообщение
ArtDen » 31 мар 2009, 11:08
Сделал так, что последовательность "Подключение к БД -> работа с данными -> Отключение от БД" происходит только в одном и том же потоке.
Заметил такой косяк: если в одном потоке идёт длительная транзакция (вставка данных), то в другом потоке в произвольный момент может зависнуть на выполнении запроса (вызове SQLExecDirectW). Как только заканчивается длительная транзакция в соседнем потоке, так сразу SQLExecDirectW "развисает", что очень странно, т.к. FB - совсем даже не блокировочник
Где вероятнее всего может быть косяк: в ODBC драйвере или моём приложении? Сейчас сделал периодический коммит при вставке данных и "зависание" в соседнем потоке практически исчезло.
PS: Firebird-2.1.1.17910-0 Win32, Firebird ODBC-2.0.0.148 win32, WinXP+SP2, двуядерный проц.
-
WildSery
- Заслуженный разработчик
- Сообщения: 1738
- Зарегистрирован: 05 июн 2006, 16:19
Сообщение
WildSery » 31 мар 2009, 12:30
В одном коннекте, что ли? А с чего коннект-то вдруг многопоточным станет?
-
ArtDen
- Сообщения: 53
- Зарегистрирован: 25 ноя 2007, 10:54
Сообщение
ArtDen » 31 мар 2009, 13:18
WildSery писал(а):В одном коннекте, что ли? А с чего коннект-то вдруг многопоточным станет?
Повторяю: Сделал так, что последовательность "Подключение к БД -> работа с данными -> Отключение от БД" происходит только в одном и том же потоке. Т.е. рабтает так:
Поток-1:
* Подключение К БД
* Работа
* Отключение от БД
Поток-2:
* Подключение К БД
* Работа
* Отключение от БД
Поток-n:
* Подключение К БД
* Работа
* Отключение от БД
Старт всех потоков и подключение к БД происходит при старте программы. Отключение и останов потоков - перед закрытием. Под подключением я имею ввиду вызов SQLAllocHandle(SQL_HANDLE_ENV, ...) и SQLAllocHandle(SQL_HANDLE_DBC, ...)
-
kdv
- Forum Admin
- Сообщения: 6595
- Зарегистрирован: 25 окт 2004, 18:07
Сообщение
kdv » 31 мар 2009, 13:56
если в одном потоке идёт длительная транзакция (вставка данных), то в другом потоке в произвольный момент может зависнуть на выполнении запроса (вызове SQLExecDirectW)
протокол коннекта к серверу локальный или tcp? строку коннекта давай.
-
ArtDen
- Сообщения: 53
- Зарегистрирован: 25 ноя 2007, 10:54
Сообщение
ArtDen » 31 мар 2009, 14:15
kdv писал(а):протокол коннекта к серверу локальный или tcp? строку коннекта давай.
И так и так пробовал. Результат идентичный.
Для ембедед:
Код: Выделить всё
DRIVER=Firebird/InterBase(r) driver; UID=SYSDBA; PWD=masterkey; DBNAME=D:\Denis\projects\database\bin\db\FbDb.gdb; CHARSET=UNICODE_FSS; DIALECT=3;
Для tcp:
Код: Выделить всё
DRIVER=Firebird/InterBase(r) driver; UID=SYSDBA; PWD=masterkey; DBNAME=localhost:D:\Denis\projects\database\bin\db\FbDb.gdb; CHARSET=UNICODE_FSS; DIALECT=3;
-
Dimitry Sibiryakov
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Сообщение
Dimitry Sibiryakov » 01 апр 2009, 14:33
Хотя вцелом Firebird действительно не блокировочник, но одно неудачное решение, сделанное в Борланде делает его таковым на счёт "раз": для Read Commited умолчательным считается режим NO_REC_VERSION. В сочетании с WAIT он как раз даёт эффект подвисания операций.
-
ArtDen
- Сообщения: 53
- Зарегистрирован: 25 ноя 2007, 10:54
Сообщение
ArtDen » 01 апр 2009, 15:07
Dimitry Sibiryakov писал(а):Хотя вцелом Firebird действительно не блокировочник, но одно неудачное решение, сделанное в Борланде делает его таковым на счёт "раз": для Read Commited умолчательным считается режим NO_REC_VERSION. В сочетании с WAIT он как раз даёт эффект подвисания операций.
Нет дело не в этом. Только что проверил: если в момент импорта подключиться к серверу не через ODBC и выполнить аналогичный запрос, то никаких тормозов не наблюдается. Такой запрос выполняется сразу, не ожидая коммита транзакции, которая выполняется параллельно.