Страница 1 из 1

ODBC и multithreading

Добавлено: 16 мар 2009, 11:55
ArtDen
Привет всем. В описании 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-хендлы созданные с этими типами.

Re: ODBC и multithreading

Добавлено: 18 мар 2009, 16:39
kdv
Вы вообще о каком драйвере, и про какую именно "многопоточность"?

Re: ODBC и multithreading

Добавлено: 19 мар 2009, 08:12
ArtDen
kdv писал(а):Вы вообще о каком драйвере,
Об этом:
http://www.firebirdsql.org/index.php?op=files&id=odbc
Version 2.0 Release Candidate 1 (RC1)
kdv писал(а):и про какую именно "многопоточность"?
Имеются ввиду потоки внутри процессов (которые в винде создаются функцией CreateThread)

Re: ODBC и multithreading

Добавлено: 19 мар 2009, 15:19
kdv
imho, все это муйня. клиентская часть допускает работу с одним коннектом только в одном треде.
Любые альтернативные движения до версии клиента FB 2.5 надо делать с синхронизацией, что ликвидирует смысл подобной "мультитредовости". Впрочем, в клиенте 2.5 всего-лишь не будет глюков, но многопоточности в одном коннекте все равно не будет (как ее нет ни у одной СУБД).

Re: ODBC и multithreading

Добавлено: 20 мар 2009, 09:04
ArtDen
kdv писал(а):imho, все это муйня. клиентская часть допускает работу с одним коннектом только в одном треде.
Любые альтернативные движения до версии клиента FB 2.5 надо делать с синхронизацией, что ликвидирует смысл подобной "мультитредовости". Впрочем, в клиенте 2.5 всего-лишь не будет глюков, но многопоточности в одном коннекте все равно не будет (как ее нет ни у одной СУБД).
С этим всё ясно. Другого я и не ожидал :)

Осталось только выяснить: могу ли в одном потоке создать SQL_HANDLE_ENV и SQL_HANDLE_DBC (подключиться к odbc-драйверу и базе данных), и в другом (одном и только одном!) потоке использовать SQL_HANDLE_STMT (выполнять sql-запросы)?

Re: ODBC и multithreading

Добавлено: 20 мар 2009, 10:18
kdv
Осталось только выяснить: могу ли в одном потоке создать SQL_HANDLE_ENV и SQL_HANDLE_DBC (подключиться к odbc-драйверу и базе данных), и в другом (одном и только одном!) потоке использовать SQL_HANDLE_STMT (выполнять sql-запросы)?
поскольку ODBC работает с сервером не волшебным образом, а через fbclient.dll, то такое не будет глючить только с клиентом FB 2.5. Пробуйте.

Re: ODBC и multithreading

Добавлено: 31 мар 2009, 11:08
ArtDen
Сделал так, что последовательность "Подключение к БД -> работа с данными -> Отключение от БД" происходит только в одном и том же потоке.
Заметил такой косяк: если в одном потоке идёт длительная транзакция (вставка данных), то в другом потоке в произвольный момент может зависнуть на выполнении запроса (вызове SQLExecDirectW). Как только заканчивается длительная транзакция в соседнем потоке, так сразу SQLExecDirectW "развисает", что очень странно, т.к. FB - совсем даже не блокировочник :) Где вероятнее всего может быть косяк: в ODBC драйвере или моём приложении? Сейчас сделал периодический коммит при вставке данных и "зависание" в соседнем потоке практически исчезло.

PS: Firebird-2.1.1.17910-0 Win32, Firebird ODBC-2.0.0.148 win32, WinXP+SP2, двуядерный проц.

Re: ODBC и multithreading

Добавлено: 31 мар 2009, 12:30
WildSery
В одном коннекте, что ли? А с чего коннект-то вдруг многопоточным станет?

Re: ODBC и multithreading

Добавлено: 31 мар 2009, 13:18
ArtDen
WildSery писал(а):В одном коннекте, что ли? А с чего коннект-то вдруг многопоточным станет?
Повторяю: Сделал так, что последовательность "Подключение к БД -> работа с данными -> Отключение от БД" происходит только в одном и том же потоке. Т.е. рабтает так:
Поток-1:
* Подключение К БД
* Работа
* Отключение от БД

Поток-2:
* Подключение К БД
* Работа
* Отключение от БД

Поток-n:
* Подключение К БД
* Работа
* Отключение от БД

Старт всех потоков и подключение к БД происходит при старте программы. Отключение и останов потоков - перед закрытием. Под подключением я имею ввиду вызов SQLAllocHandle(SQL_HANDLE_ENV, ...) и SQLAllocHandle(SQL_HANDLE_DBC, ...)

Re: ODBC и multithreading

Добавлено: 31 мар 2009, 13:56
kdv
если в одном потоке идёт длительная транзакция (вставка данных), то в другом потоке в произвольный момент может зависнуть на выполнении запроса (вызове SQLExecDirectW)
протокол коннекта к серверу локальный или tcp? строку коннекта давай.

Re: ODBC и multithreading

Добавлено: 31 мар 2009, 14:15
ArtDen
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;

Re: ODBC и multithreading

Добавлено: 01 апр 2009, 14:33
Dimitry Sibiryakov
Хотя вцелом Firebird действительно не блокировочник, но одно неудачное решение, сделанное в Борланде делает его таковым на счёт "раз": для Read Commited умолчательным считается режим NO_REC_VERSION. В сочетании с WAIT он как раз даёт эффект подвисания операций.

Re: ODBC и multithreading

Добавлено: 01 апр 2009, 15:07
ArtDen
Dimitry Sibiryakov писал(а):Хотя вцелом Firebird действительно не блокировочник, но одно неудачное решение, сделанное в Борланде делает его таковым на счёт "раз": для Read Commited умолчательным считается режим NO_REC_VERSION. В сочетании с WAIT он как раз даёт эффект подвисания операций.
Нет дело не в этом. Только что проверил: если в момент импорта подключиться к серверу не через ODBC и выполнить аналогичный запрос, то никаких тормозов не наблюдается. Такой запрос выполняется сразу, не ожидая коммита транзакции, которая выполняется параллельно.